From: Sunil S. <sh...@bo...> - 2010-05-03 13:59:48
|
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. Once done, regular uidl and fastuidl will not eat up resources. Note that fastuidl is not the source of this problem. -- Sunil Shetye. |