Re: Bug#90867: Menu is more important than it would seem
On Mon, Mar 26, 2001 at 10:07:05AM -0600, Steve Greenland wrote:
> On 26-Mar-01, 06:46 (CST), Henrique M Holschuh <hmh@debian.org> wrote:
> > On Mon, 26 Mar 2001, Jules Bean wrote:
> > > If that hit can be reduced to a single call to stat() or fstat() (and
> > > I can't see why it can't) then I can't believe that amounts to much of
> >
> > It can, and the performance hit is negligible IMHO. Heck, debian cron can
> > detect and reload configuration on the fly for a file and an entire
> > directory of files, and it does that check every minute. Nobody ever
> > complained, AFAIK.
>
> Except when I checking something that wasn't getting cached, and caused
> people's laptop disks to spin up every minute. They complained then (and
> quite justifiably, too).
But, if you make the check every time you bring up a menu, then it
/will/ be cached to memory. If you haven't brought up a menu for so
long that the cache is lost, then it seems not unlikely that the code
which loads the menu is also swapped out, and the disk access is going
to happen anyway.
I'm hazy about disk caching/ext2fs interactions, but doesn't stat()
hit a specific 'status' area of the disk, which is among the most
likely bits to be cached anyhow?
Jules
Reply to: