Re: [fetchmail-devel] save_str problems.

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

Am 03.05.2010 14:33, schrieb Rainer Weikusat:
> Sunil Shetye <sh...@bo...> writes:
>> Quoting from Rainer Weikusat's mail on Mon, May 03, 2010:
>>>> Matthias, you have said that the regular uidl code is faster than the
>>>> fastuidl code for 10000 uids. Do you mean while processing 10000 uids
>>>> on the fetchmail side or while getting 10000 uids from the server?
>>>>
>>>> The fastuidl code downloads less UIDs from the server and hence has to
>>>> compare less UIDs to check for new mail. If there are very few new
>>>> mails, then the fastuidl code is expected to save a lot on the string
>>>> comparisons.
>>>
>>> It is conceivable that the string comparisons take less wallclock
>>> time than repeatedly asking a server for an UID and waiting for the
>>> replies does. IMHO, this is still a bad tradeoff because 'e-mail
>>> download' is a background batch job and even on a single-user
>>> workstation, minizing e-mail download time at the expense of directing
>>> more resources away from the interactive jobs the user interacts with
>>> doesn't really make sense except if one is using a uplink whose cost
>>> is proportional to the time spent 'online'.
>>
>> As Matthias has already said, the better solution is to use the
>> appropriate data structures like trees or hashes or vectors in order
>> to cut down both searches and modifications.
> 
> Sorry, but you are seriously lost in space here. I have no idea which
> thought could have motivated you to reply with this to my attempt at
> an explanation of the 'faster with 10000 UIDs' statement.

Guys, I was making that confusing statement, and it referred only to the
network and wallclock consideration, assumed networks with big
bandwidth-delay product, and it also pretended that someone had already
fixed the complexity of the UID handling (which hasn't happened to the
best of my knowledge; I have started hacking a bit on it, but not sure
if I'll make it, or drop it and leave it for a later release using C++,
if it turns out it's too much of a hassle to do in C).

fastuidl will reduce the network traffic considerably, and will also
save time on low-latency links.

Whether we do fastuidl or not, for any nontrivial amounts of messages
kept on the server for POP3, we need to fix the code to get rid of the
O(n^2) complexity.