On 1/5/07, Joey Hess <[EMAIL PROTECTED]> wrote:
Wim De Smet wrote:
> You're saying two things here. First you're saying it open()'s every
> file you come across, then you say it lists every directory. I've
> noticed it does list all files in a directory on the path you type
> (which on a system with sufficient ram only goes slow once but is
> indeed very annoying) but I don't think it's open()ing every file in
> those directories. This would require an ordinate amount of processing
> power not to mention disk I/O which I'm just not seeing.
Try browsing to /usr/bin. As I wrote on this list last time this topic
came up:
The amazing thing is what it's doing. This includes:
open /usr/bin
getdents
for each file
stat it (to get modification time?)
That's reasonable, and most programs would stop here with about .2
seconds used. Although a non-generic "pick a program to use" chooser
shouldn't need to even care about getting modification times, which
would bring it down to more like 0.001 seconds used.
k this is the completion running. stat to get filetype?
for each file
open file
use fstat on it (to get modification time? again?)
read 4k of file contents, apparently to determine the file type
to use in displaying various (identically meaningless) icons
The second loop is the killer when it needs to read 3000 files. Tens
of thousands of system calls, and the disk seeking all around to read
some 12 mb of data. Pretty absurd indeed.
This behavior is still happening with the current version, although
the second loop only runs when it needs to display the content of a directory
in the list box, so it can sometimes be avoided if a filename is typed in.
Is there a bug in the gnome tracker? I couldn't find one but just had
a cursory look.
greets,
Wim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
