Re: [fetchmail-devel] An actual patch

[Matthias A. <mat...@gm...>]

Am 24.05.2010, 21:30 Uhr, schrieb Rainer Weikusat:

> Below is a diff of my modified fetchmail tree against the 6.3.17
> release tree. This should still be considered somewhat experimental
> because it has so far only been tested with a single e-mail account in
> 'oneshot' mode. According to prelimnary measurement, the modification
> seems to be advantageous if there are sixty or more e-mail kept on a
> server. Additional changes I haven't mentioned so far:

First impression: looks good.

(Athlon XP 2500+ with slowish DDR RAM, probably 6 - 7 years old)

With 550 messages, barely a difference, CPU time down from 20 to 15 ms.

With 16,400 messages, a huge difference, CPU time down from 62 to 1.3 s  
(includes --fetchlimit 100 and TLS either time).

> 	- I've dropped the l from the uid in all the names. 'UIDL' likely
>           means 'uid listing' and hence, what is listed must be an uid

indeed - UID means "unique identifier"

> 	- The message number index now grows downwards from the
>           message count to the lowest-numbered 'interesting' ('new')
>           message seen. In order to be able to also use this, I've
>           changed the POP3 'stock uidl code' to only record the
>           message numbers of 'new' messages in keep mode and to treat
>           a NULL return to the 'find by message number' operations as
>           'message is old'. The message number index will either only
>           be large enough to hold the new message numbers or (at
>           worst) be large enough to hold the lowest number of a
>           'seen' message tested by the fastuidl code

For reasons beyond me, --fastuidl 5 does not currently appear to work.  
Fetchmail pulls the whole UID list.
Haven't checked yet if that's an artifact of your code.

> 	- I've tried to document everything not completely trivial in
>           form of comments in the uid_db.c file. IMO, this is a mixed
>           blessing because an algorithm is not necessarily easier to
>           understand when described in natural language and everybody
>           contemplating to do something with code needs to understand
>           that, anyway ...
>
> After sending this mail, I will integrate this into our 'product
> fetchmail' and I may be able to publish some real comparisons between
> old and new code tomorrow.
>
> NB: The Makefile.am change should probably be moved to the POP3
> section of Makefile.am

Move it to libfm_a_SOURCES=... - that lets the linker sort out if the  
uid_db code is needed.

-- 
Matthias Andree