Re: faster gnus-thread-latest-date

[Dan Christensen <jdc@uwo.ca>]

Daniel Pittman <daniel@rimspace.net> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> Actually, in my tests it is only slightly faster.  Still, the code is much
>> simpler, so unless someone can think of a reason not to, I think the change
>> should be made (after someone else checks it over and tests it).
>
> Replacing reasonably sensible behaviour (use delivery time if no
> accurate time is available) with nonsense (delivered before everything
> else if no accurate time is available) doesn't look like a usability
> win to me. :(

I'm not sure what you mean, here.  When taking the maximum of a list of
data, replacing bad data with the previous thing on the list or with a
very small value won't change the maximum.

>> However, I think there's an orthogonal change which could greatly
>> improve the sorting speed.  For a group I have with about 6000
>> messages and maybe 1000 threads (?), gnus-thread-latest-date is
>> called 31028 times, taking about 10.5 seconds in total.  If the
>> output from gnus-thread-latest-date was cached, that would reduce the
>> number of computations of this date by at least a factor of 5, and so
>> would greatly reduce the time needed to enter the summary buffer.
>
> This sounds like a vastly more useful way to fix the problem; the results
> below show that memoizing the function returns better performance
> improvements.

Which results below?  How did you memoize the function?  And how does it
compare to the trick of caching the results as a text property that I
discussed in a later message?

Dan