[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: low performance of kio
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-04-21 9:35:41
[Download RAW message or body]

mosfet wrote:
> 
> Waldo Bastian wrote:
> >
> > > Forgive me if this sound naive, but I was under the impression that KIO
> > > should be used whenever possible, in order to promote said "transparency".
> >
> > Whenever it makes sense, yes.
> >
> > > If you insist that ppl use which ever method is more appropriate, then use
> > > fread for local files and nfs or ftp for network operations, and skip KIO
> > > altogether.
> >
> > And blocking your whole application on slow NFS reads... I think you will
> > love GNOMEs gmc.
> >
> 
> Or ls, or cp ;-)
> 
> Remember, the vast majority of our users probably never used, nor never
> will use, NFS. Killing local file performance, which affects all users,
> to handle a situation that affects by far a minority of them is not
> acceptable IMHO. I'm pretty confident most KDE users are using things
> like ppp and *no* network filesystems at all - be it NFS, SMB, Novell
> NCP, etc...
> 
> Now again, I'm not saying that launching a separate process and not
> blocking is bad for NFS. It's bad for I/O with local files in many cases
> tho, and that is going to be occuring in the vast majority of cases. You
> optimize for *that*, the most common situation that affects users the
> most, and include hacks for the infrequent scenarios. Especially since
> Coolo seems to already have the beginning of a way to check and do the
> right thing :)
> 
> Providing this as an option in KIO is much nicer than requiring
> developers not to use KIO at all and fread/fwrite when speed is
> important. If you do that (which is the suggested solution), you have
> all the problems with NFS *anyways*. All you managed to do is require
> the developer to maintain 2 sets of code.
> 
> Just more of my 2c from someone who remains pretty much clueless about
> the internals of KIO ;-)
> 
Well, as Waldo already pointed out: optimizing the block size should
help already a lot. And an optimization for "file:" is not the problem
I guess. But it's a f**ing work to add this and do it right.

Greetings, Stephan

-- 
It said Windows 95 or better, so in theory Linux should run it
                                                GeorgeH on /.

[prev in list] [next in list] [prev in thread] [next in thread]