2.6 Release -- SCheme

[Donald Allen]

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.

/Don

>
>        Mike
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel