Re: [Pan-devel] Re: [Pan-users] Speed of pan

[Duncan]

On Friday 01 November 2002 10:02, Carl Wilhelm Soderstrom wrote:
> On Fri, Nov 01, 2002 at 08:46:37AM -0800, Charles Kerr wrote:
> > The startup time is due to Pan walking through your cache files to find
> > out what you've got there.  I suppose we could store these message-ids in
> > a file and use that instead of walking through the cache directories. 
> > That should make Pan start up immediately regardless of the cache size...
>
> what about starting the GUI, and walking the cache with another thread
> running in the background?
>
> as I understand these things, that would let you bring up the GUI, and
> while you couldn't get a display of data right away, the user would at
> least see a response to their action, and it would 'seem' faster.

That is essentially what newer PANs do.  (Don't remember whether it was the 
0.12 or 0.13 series that changed it, but that is the way it works, now.)

It does create possible timing issues, however, including one which is 
certainly apparent as currently implimented -- if you start up PAN with a 
large cache, and then enter a group, it will show all the headers it should, 
but will show only the messages it has had time to load, as cached.  If you 
then leave the group, and come back, there will be more messages displayed as 
cached.  Eventually, it will show all the cached messages.

This isn't a big issue if you have auto-d/l upon entering a group, off, as I 
do, and recognize what is going on.  However, with it on, it can create some 
confusion, as it can for users that don't realize what is happening. 

I was the one that requested (and got) the maximum cache size increase from 1 
G, to 20 G.  I don't use that, but I do have mine set for 4 G, and was having 
problems with messages disappearing b4 I could read them, at the 1 G size, 
d/ling more than a G in a session at times (cable modem connection =:^).  I 
had been manually setting the cache size, in the config file, but found it 
resetting occasionally, when I changed something in the GUI settings, and 
lost a bunch of cache several times.  Thus, I was rather upset, when it 
seemed to be doing that again, with the faster load time and the larger 
cache, until I realized it was just loading the messages in the background, 
and hadn't gotten them loaded yet.  It wasn't erasing already d/led messages 
before I could get to them, as it had with the smaller cache.

Anyway, with the size of cache I operate with, often 2+ gigs, its certainly 
noticable on my 1.2 GHz Athlon, w/ a 7200 RPM ATA 100, 100G hard drive. (I 
have a couple smaller drives as well, but they hold my legacy MSWormOS 
installation, which I haven't booted in months.  The newer 100 G drive is 
100% Linux, ReiserFS formatted, in several separate partitions, of course.)

BTW...  on the ATA 100 and 133 topic...  A single drive isn't going to even do 
half of that, as people have noted, except for the usually 2-8M of 
drive-cached data.  When it is actually coming off the disk, not out of 
drive-cache, 40-some MB/sec isn't to bad.  The newer ATA bus transfer levels 
do come into play, however, if you've two drives and are accessing them both, 
as would be the case with RAID.  In that case, the older ATA 66 and slower 
specs are potentially slowing things down, seriously, when you get to  UDMA 
33s and slower, as that won't even handle the output of a single drive, any 
more.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin