2.6 Release -- SCheme
donaldcallen at gmail.com
Sun Jan 1 00:06:59 EST 2012
On Sat, Dec 31, 2011 at 6:41 PM, Mike Alexander <mta at umich.edu> wrote:
> --On December 31, 2011 6:31:34 PM -0500 Donald Allen
> <donaldcallen at gmail.com> wrote:
>> If there is agreement among the developers that this is an attractive
>> alternative to Guile, I would advise doing some prototyping to
>> evaluate the performance of Python for report generation. My guess is
>> that it will be faster than Guile, but that's only a guess. It should
>> be tested before committing to it. One of the problems (and not the
>> only one) with the current report system is performance, and it would
>> not be smart to invest a lot of effort in a new system that had the
>> same problem.
> Having looked at a number of reports, and optimized some by factors of 5 or
> more, I don't think changing the language will help this problem. Even if
> the Guile interpreter were infinitely fast, some reports would still be slow
> because of the algorithms they use.
If the Guile interpreter were infinitely fast, we wouldn't be having
this discussion; the reports would be infinitely fast :-)
They often do multiple passes over
> large searches through the Gnucash data. That is where the time often goes.
> Of course if all the reports were rewritten, these problems might be fixed
> in passing.
A bad algorithm written in a fast language running on a fast computer
can be unacceptably slow. A good algorithm written in a slow language
on a fast computer can be unacceptably slow. Yes, there's more
leverage in the algorithm, but the language can matter, too.
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel