[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:19:07
[Download RAW message or body]

Maniac wrote:
> 
> On Thu, 20 Apr 2000, Uwe Thiem wrote:
> > On Thu, 20 Apr 2000, mosfet wrote:
> >
> > > This is kindof what I was thinking but I was too much a newbie with KIO
> > > to mention it ;-) I thought one of the main advantages of KIO was to be
> > > able to use the same chunk of code for both local and remote files >:)
> > > I'm totally ignorant here but perhaps it would be good to add hacks to
> > > KIO that optionally just use normal I/O without slaves for local files
> > > but generate the same signals as other jobs (reading/writing a chunk of
> > > data then generating a signal)? Dunno if this is possible or not.
> 
> After listening/reading this thread I am going to add my 2 cents worth
> <dons asbestos suit>
> If I understand the root of the problem...
> It is the inefficient design/performance of KIO that is the problem and the
> IMHO good idea of using existing code instead to use an overused term
> "reinvent the wheel" that is the problem here.
> People/developers want to take advantage of what is offered in the Open Source
> world and want to expand on that.  Lets remember that we are creating libraries
> that should be as (too use another overused term "bulletproof")  and as
> error-free and optimized as possible.  Would you like to have to
> re-write/re-compile every "standard" clib/c++lib function that we as developers
> take for granted in order to have "acceptable performance"?
> >From what I gather from the original post about performance
> w/ KIO 200-250 kb/s
> w/o KIO 2500-3000 kb/s
> Which would you consider to be better?
> 
> So what should we developers consider when we develop applications...
> 
> I am only trying to shed some light on the problem we have here.
> 
> I for one considering the (even if the margin of error was off by as much as
> 50% between the 2 ) would not touch KIO .
> I would look to improve the performance;  not go and add more
> functions/capabities  to a library that (IMHO is slow).
> 
> Yes I can see that time pressures could have affect "features"  but if you're
> designing libraries that are supposed to be used by a multitude of applications
> wouldn't you want the libraries to be the best that they could be?
> 
Haem? You _only_ read the thread, right? KIO opens URLs from all over
the
net, and only comparing the performance is like comparing fish and wood
in smelling and saying wood smells better -> eat no fish.

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]