Speeding up gnucash

[AC]

On 2/26/2014 21:56, John Ralls wrote:
> 
> On Feb 26, 2014, at 9:33 PM, AC <gnucash at acarver.net> wrote:
> 
>> On 2/26/2014 20:05, John Ralls wrote:
>>>
>>> On Feb 26, 2014, at 7:14 PM, AC <gnucash at acarver.net> wrote:
>>>
>>>> I'm currently running the Windows version 2.4.15.  Is there a way to
>>>> speed up the read and write operations?  Right now when I save my
>>>> updates it takes about two minutes to write everything to disk.  When
>>>> loading, it can sometimes take a while to load the file and populate the
>>>> registers.
>>>
>>> Heh. You think 2.4.15 is slow, try 2.6.1.
>>>
>>> Unfortunately, reading a large file and creating all of the objects or serializing all of the objects and writing them back into a file is slow. After a couple of bug reports about files being corrupted by invalid UTF8 and ASCII control characters, the latter of which are illegal in XML, 2.6 introduced checking every string for invalid characters. That slows down loads, imports, and saves even more.
>>>
>>> The only thing you can do is to shrink your file. There's no automatic way to do it: You need to first make a backup, then pick a date and create an Opening Balance transaction for that date for every account. Once you've done that, you can delete all of the transactions in before the date.
>>
>> What about running a database (I see it mentioned in the FAQ about a DB
>> backend), is that possible in the Windows implementation?  Not having
>> the old transactions makes finding payees hard (autocomplete would be
>> missing data).
> 
> For 2.4, 2.6, and probably 2.8, the SQL backend loads everything into memory just like the XML backend does. We want to change to proper database use for a bunch of reasons, but we need to do a lot of code cleanup before we can do that. The code cleanup is the focus of the 2.7->2.8.0 development cycle. That's a long winded way of saying that the SQL backend won't help with load times anytime soon. 
> 
> On the other hand, the SQL backend saves incrementally, so that part is much faster. There's a caveat that there may be some corner cases where the SQL backend doesn't save at all, so be very careful using it at first. If you can use the SQL backend, particularly with MySQL or Postgresql (meaning that you know how to administer one of those servers), you can just leave GnuCash running most of the time and avoid the load time, assuming that your usage doesn't bump up against any of those corner cases... but if it does, that could be good, too, because then we'd know about that corner case and could fix it.

No problem, I already run many MySQL servers on other machines here.
One more isn't an issue.  I'm hoping there's some documentation on how
to set up gnucash to use the DB backend on Windows.  And I do usually
leave gnucash running so the incremental saves would be great, that's
usually what's happening to cause the slowdowns.