2025-06-20 GnuCash IRC logs
01:06:48 <chris> ah the 40% speedup happened on e80249ce2b
01:08:12 *** hamaryns has joined #gnucash
01:08:12 *** ChanServ sets mode: +v hamaryns
01:26:15 *** hamaryns has quit IRC
01:29:17 *** hamaryns has joined #gnucash
01:29:17 *** ChanServ sets mode: +v hamaryns
01:37:35 *** fell has quit IRC
01:38:18 *** hamaryns has quit IRC
01:38:54 *** fell has joined #gnucash
01:38:54 *** ChanServ sets mode: +o fell
01:45:04 *** chris has quit IRC
01:52:54 *** hamaryns has joined #gnucash
01:52:54 *** ChanServ sets mode: +v hamaryns
01:52:56 *** hamaryns has quit IRC
05:33:24 *** chris has joined #gnucash
05:33:24 *** ChanServ sets mode: +v chris
05:33:24 *** gncbot sets mode: +o chris
06:58:30 *** chris has quit IRC
08:19:11 *** chris has joined #gnucash
08:19:11 *** ChanServ sets mode: +v chris
08:19:11 *** gncbot sets mode: +o chris
08:47:17 <chris> jralls: here's an easy speedup for loading datafile; in Account.cpp#L334 priv->splits.reserve (1000);
08:48:01 <chris> crude benchmarks cli/loading/running report improves 15-20%
08:49:04 <chris> the datafile has num(total_transactions) but not num(account_transactions) so there's no way to predict the number of txns per account
09:56:11 *** chris has quit IRC
15:15:58 *** jralls-m1 is now known as jralls
15:16:13 *** ChanServ sets mode: +o jralls
15:26:54 <jralls> @tell chris So the simple if a bit wasteful way would be to reserve some fixed number of splits for each account and then shrink_to_fit after the load. There is a way to find out how many splits per account with the SQL backend: SELECT COUNT(*) FROM spllits WHERE account_guid = `foo`.
15:26:54 <gncbot> jralls: The operation succeeded.
15:27:52 <jralls> @tell chris To do the same in XML would require us to load the XML as a DOM instead of using SAX. I suspect that would cost more than reserving the split vectors would save.
15:27:52 <gncbot> jralls: The operation succeeded.
15:29:31 <Simon> the XML file has total transactions and total accounts first, so you could estimate an amount to reserve
15:29:53 <Simon> of course, memory is cheap so I'd just reserve total_transactions for each account
15:33:13 <Simon> I just tried added a reserve of 65536 and 1000 but there's no change to load time for either
19:59:27 *** chris has joined #gnucash
19:59:27 *** ChanServ sets mode: +v chris
19:59:27 *** gncbot sets mode: +o chris
20:02:31 <chris> ok maybe reserve(num) didn't speed up tremendously.... however on average it was faster with reserve than without
20:03:34 <chris> wrt loading, it's the xaccTransBegin/Commit pair that seems sluggish... creates a whole copy during load, and sanity checks all - including capgains calc, before discarding the copy
20:04:09 <chris> I still can't figure out if the cap-gains.cpp calcs are actually being used in practice
20:15:28 *** chris has quit IRC
23:10:00 *** jonakeys has quit IRC
23:10:08 *** jonakeys has joined #gnucash
23:42:58 *** chris has joined #gnucash
23:42:59 *** ChanServ sets mode: +v chris
23:42:59 *** gncbot sets mode: +o chris
23:46:06 *** chris has quit IRC