Re: Suggestion for file type detection approach

[Arvind Narayanan <arvindn meenakshi cs iitm ernet in>]

On Sun, Jan 04, 2004 at 11:32:04AM -0500, Jeffrey Stedfast wrote:
> yes, the directory scan was already cached - pretending to test
> first-run is bullshit because you don't know if anything may have
> already scanned the directory and thus pre-cached it.
I don't see the logic here. We do want to test the first run
performance, because:
 - We want the worst case performance to be good. Average case
   nautilus performance is *already* efficient.
 - Its not just reading the contents of the directory, its reading
   *every file* in the directory. Its safe to say that this wouldn't
   have been cached unless the user visited the directory earlier
   in nautilus.
> 
> unless someone knows of a way to be sure that there's no cache, it's an
> impossible-to-do-fairly task.
> 
> anyways... about gnomevfs-ls:
> 
> - seems gnomevfs-ls stat()'s some of the mime-info files multiple times
> even after it has opened/read them in.
> 
> - read()'s 4k from each file (4k is a pretty efficient size to read, but
> if we don't *need* 4k, it might be overkill - file seems to read much
> smaller chunks - 32 bytes and more if it needs it). I guess what should
But I doubt if it is physically possible to read less than 1K from the
disk? In any case I would expect seek time rather than the bandwidth to
be the bottleneck, so size would probably not matter much.

[snip] 
> anyways, because pre-caching makes such a huge impact on sniffing, it
> does suggest that the process is i/o bound (duh, makes sense). and so
> cacheing these sniff results in EA or some other file or something might
> definitely be a way to go.
I agree :)

Arvind
-- 
Its all GNU to me