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

List:       kde-devel
Subject:    Re: low performance of kio
From:       Maniac <Maniac () alltel ! net>
Date:       2000-04-21 2:36:55
[Download RAW message or body]

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?

<removes Asbestos suit>
 --------------
Maniac@alltel.net
A single tasking guy in multi tasking world.

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