Code formatting Re: SQL backend performance

[Geert Janssens]

On Wednesday 24 February 2010, Phil Longstaff wrote:
> On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote:
> > > So I applied the same treatment to load_splits_for_tx_list,
> > > substituting g_list_prepend for g_list_append inside the
> > > split-fetching loop and reversing the list on completion of the loop.
> > > I rebuilt and tried again and now my data loads in about 9 seconds,
> > > approximately the same as the xml file and about a factor of 5
> > > improvement! I haven't tested it yet, but I believe we'll see a nice
> > > improvement with sqlite3 as well, since this code is not specific to
> > > either database.
> >
> > This is extremely good news! Thanks a lot for looking into this and
> > reminding anyone here to read the docs of the container types we're
> > using...
> >
> > I guess the same (g_list_prepend vs. append) might show up in the XML
> > backend as well...
> >
> > As for the patch and indentation: Indeed we discussed and agreed on some
> > common indentation last summer, and we agreed on using the tool astyle to
> > reformat the code as decided. See
> > http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121.html
> > and my commit r18675 recently. I didn't apply this to the full source
> > tree so far in order not to destroy some people's diffs which are still
> > waiting to be applied... I think the directory you're mentioning wasn't
> > run through astyle recently, so that would explain this issue.
> 
> I think the best way to handle this formatting is to create an options
> file (perhaps src/c-code.style) which is then used everywhere:
> 
>     astyle --options=~/gnucash/src/c-code.style *.[ch]
> 
> Christian, could you create such a central file with the options you are
> using?
> 
Agreed on the idea of an options file, but it should IMHO not be in src. I'd 
prefer to see it in util.

> Does anyone know of a scheme formatter?
> 
Unfortunately, no.

> Phil
> 

Geert