Re: Possible speed enhancement

[Alexander Larsson <alexl redhat com>]

On Thu, 2008-10-02 at 00:26 +0200, Milosz Derezynski wrote:
> I just would like to add that the argument "Nautilus/FileChooser
> wasn't design for X/Y/Z" is a really bad one, just by principle.
> 
> FileChooser and Nautilus take around 4-5 Seconds to display my
> "Pictures" folder which contains *only* around 150 pictures. Clearly
> this is annoying (on a SATA-2 500GB drive, 2GB RAM, 2x Athlon 64 X2
> 4400+ CPU, running GNOME). An implementation should always aim to be
> as fast as possible, hiding behind intentions only means to be lazy.
> On the other hand if you'd say you don't want to spend time optimizing
> this it'd be ok but just saying it wasn't made for this and that
> sounds like an elusion.

All programming is about choice. If you optimize for top speed instead
of features you should list only the name of files and no more
information[1]. That is really fast. If you like more features you loose
performance, more for each feature you choose to have. The decision made
that is discussed above was that showing the right type of files that
have no extensions is more important than performance showing files with
no extensions, and has nothing at all to do with lazyness. Given this
choice we should of course aim to be as fast as possible, but we should
not allow only performance affect our decisions about user visible
behaviour.

Now, I don't claim that nautilus is the fastest thing in the universe,
and if you have a case where its slow, be my guest and try to profile
and optimize it. However, having spent several years mainly working on
nautilus optimizations I get kinda annoyed at outbursts like "being
lazy". They are for sure not a good way to get me to fix something
you're interested in.


[1] This will minimize i/o in that you only need readdir() not stat()
calls. This is similar to how the sniffing causes even more i/o than the
stat() call.