Setting up gnucash to use postgesql back end - close but no cigar ...

[Sébastien de Menten]

Hello John,
You emphasized a couple of times that a) no CPU architecture supports
decimals b) sqlite does not support decimals natively, c) storing string
could be less performant.
And I agree on all of these points.
However, if time spent by gnucash on number mgt is marginal, these points
may not be that critical ... and so it can open/widen the horizon of
possibilities in terms of evolutions.
No more, no less than that (and sorry to have been probably confusing in my
reasoning).
regards,
Sebastien


On Sun, Mar 15, 2015 at 1:12 AM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Mar 14, 2015, at 11:24 PM, Sébastien de Menten <sdementen at gmail.com>
> wrote:
>
> On Sat, Mar 14, 2015 at 2:04 PM, John Ralls <jralls at ceridwen.us> wrote:
>
>>
>>
>> Maybe. It would depend upon what's in a book and what operations are done
>> in a session. It would take a lot of work to develop a good set of
>> benchmarks to evaluate that. Since you're the one beating the horse to
>> death, perhaps you can spend some time working on it.
>>
>> I did a quick valgrind(callgrind) to profile gnucash on the "open
> document" operation.
> You can see in the first screenshot  the top "time consuming" functions.
> I also filtered on all xacc functions.
> Even though it may not be easy to see immediately if the "rational
> arithmetic" takes a long time, at first sight, I do not see them coming on
> the top.
>
> <Screenshot from 2015-03-14 15:16:22.png><Screenshot from 2015-03-14
> 15:21:57.png>
>
>
> So? What part of "It would depend upon what's in a book and what
> operations are done in a session. It would take a lot of work to develop a
> good set of benchmarks to evaluate that." do you not understand?
>
> What's your point in banging this drum anyway?
>
> Regards,
> John Ralls
>
>