> If anyone sees this problem and updating to gtk+-2.4.14 or gtk+-2.6.2
> doesn't solve it, I'd like to hear about a way to reproduce it. We
Just to make it clear: this is *not* a problem with the gimp code :)
After updating to debian's "2.6.2-2", I made a few tests (with gedit,
though, which should have similar performance).
Opening a large directory over NFS took well over 8 minutes, which is
probably quite an improvement, but it's not quite acceptable.
(testing with gimp on smaller dirs shows similar performance, which is not
surprising, as it's a gtk+ issue)
For comparison: CV (which does NOT do file"content"type detection but only
checks wether something is a directory or not) requires 23 seconds for
the same directory, while the good old xv (which also doesn't do content
detection) takes around 88 seconds between opening the schnauzer and
seeing the dir contents.
strace'ing gedit shows that the only change seems to be that instead of
reading 128k of every file, only 8k is being read. One obvious problem
is that it first stat's all files _then_ reads them, which is quite
inefficient even for local filesystems.
However, the detected content types are not even being
displayed. Seemingly, they are not used at all, so the obvious
improvement, as for the gimp file save dialog, would be to not gather
costly data that is not being used or displayed (at least by default).
(Not that this is a job for the gimp developers...)
(Of course, I only *guess* that it's reading the files to detect content
types, I have not *verified* that it does it for that purpose).
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@xxxxxxxx
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
