FTP performance (was Re: Performance)

Alexander Larson wrote:
Date: 10 Nov 2003 10:38:09 +0100

On Sat, 2003-11-08 at 19:55, Julien Olivier wrote:
On Sat, 2003-11-08 at 09:58, Alexander Larsson wrote:
> On Fri, 2003-11-07 at 14:48, Alberto Ruiz wrote:
> > El vie, 07-11-2003 a las 09:35, Alexander Larsson escribi?:
> > > Of course we work on performance when we can
> > I would like to help on this task, which are the key code parts that may
> > cause this kind of problem, I mean, if I could do something, where
> > should I start?
> If we know something was slow we would fix it. The main work with
> optimization is figuring out why its slow.

One thing which is _very_ slow is displaying a folder containing - say -
1000 MP3s.
I guess the reason is that Nautilus parses each files to determine its
I don't know how konqueror handles it but it's quite instantaneous.

The problem is that, now, Nautilus doesn't display the content before
everything is loaded. So you quickly notice this problem on crowded

Wouldn't it possible to simply display the files without determining
their MIME-Type and, later, re-scan the folder to get the MIME-Types and
display the right icons/thumbnails ?

I think thats would be worse.

You quickly get the wrong data, and then you can't use it while the data
is moving around to the final correct state. And this would make the
total time longer than the current time.

My guess is that konqueror is faster in this example because it matches
mime types for mp3 by extension, instead of sniffing. I prefer getting
correct results over speed though.

Of course you can wait on local directories. But over ftp ? nfs ?
Here and now, nautilus (2.4.0) is just unusable to transfer files via ftp from directories with thousands of files (example : rpms repositories) : it takes too much times to render the content of the directory, then too much time to begin the download of the file you select. In the latter case, I've got here more than a minute of huge processor activity sessions alternating with huge net activity sessions, before the real download of the file begins.

I think there is at least one problem for rendering ftp directories : nautilus seems to rerender the icon view each time another file is added to the directory content during its listing via ftp (you can see that the icon appear one to one). It's specially long with the list view and the icon wiew, when you deselect the "remember icon position" option. But even when a nautilus window is set to remember the icons positions, it's still very long to render it.

The second is : why all this net traffic before beginning a ftp download ?

That's why I use gftp for ftp :-)
Bertrand Dekoninck

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]