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

[Jeffrey Stedfast]

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.
-- 
Jeffrey Stedfast <address@hidden>