FTP performance (was Re: Performance)

[Bertrand <anneetbertrand wanadoo fr>]

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
> > MIME-Type.
> > 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
> > folders.
> >
> > 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