On Sat, Dec 31, 2011 at 6:41 PM, Mike Alexander <m...@umich.edu> wrote: > --On December 31, 2011 6:31:34 PM -0500 Donald Allen > <donaldcal...@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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel