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

[Jeff Vian]

I like your idea Jeff.
Why does the article list need to show the cached articles at all for 
those cached from an earlier session?

If the scenario as Jeff mentions is followed then:
1. user requests download
2. pan checks cache
   if cached,  use the cached copy
   if not cached, download it
Regardless of the option in #2, mark it as cached in the list for this 
session.

This would eliminate a LOT of overhead in scanning the cache on startup 
and the only thing lost AFAICT would be the cache icons at startup time.




Jeffrey Stedfast wrote:

> Pardon me for my ignorance, but why does Pan have to check the cache at
> all on startup?
>
> Keep in mind, I'm not all that familiar with Pan cache internals nor
> NNTP/News in general, but to me a cache should be implemented in such a
> way as:
>
> 1. reader makes a request for (an) article(s)
> 2. if article exists in cache
>  then read from the cache
>  else download article and attempt to cache it (if fail, unlink() so
> that the next request for the same article doesn't get an empty or
> truncated file)
>
> If things worked this way, there shouldn't be a need to scan the cache
> on startup.
>
> oh... I may have just realised what it scans the cache for - to put an
> icon in the article list to denote if the article is cached or not?
>
> (it's late, smack me if I'm just not getting it)
>
> Jeff
>
> On Fri, 2002-11-01 at 20:41, Duncan wrote:
>  
>
> > 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.
> >