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

List:       kde-core-devel
Subject:    Re: optimizing CopyJob, unconnected signals ?
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-11-12 22:33:08
[Download RAW message or body]

On Sunday 12 November 2000 22:47, aleXXX wrote:
> On Friday 10 November 2000 15:59, David Faure wrote:
> >On Friday 10 November 2000 16:05, aleXXX wrote:
> >> Hi,
> >>
> >> CopyJob emits signals like copying(...), moving(...) and others.
> >> I could not find any connect(...) call which connected them to any slots.
> >> Can they be removed ?
> >
> >No, they are necessary for the Undo feature.
> >Look at libkonq/konq_undo.cc for the connects.
> 
> I had a look. There are only the signals copyingDone and movingDone connected.

Oh, indeed. Yes, copying() isn't used indeed.
It's only there because ProgressBase knows about it and connects to it, but
we don't use it this way anymore. The whole reason for the ProgressBase, 
StatusbarProgress, and DefaultProgress classes were to provide several ways
to connect to a job's signal, for instance to get the signals directly connected
to a statusbar. This is from the previous KIO design and is not used by any KDE 
app AFAIK, since we have kio_uiserver.
I just don't know if we want to get rid of that or leave it. It's Matt's stuff, really....

> Additionally I made some measurements on my system.
> 
> Calling a member function 1.000.000 times took 0.11 seconds, emitting a 
> signal connected to a slot which does exactly the same 1.000.000 times takes 
> 6.5 seconds, so in tight loops signals/slots are significant for performance.

Ok, good to know. But what about emitting a signal that isn't connected to
anything (as it's the case with copying()). Does that take much time ?
Hmm, I guess it's something in between, since it goes half the way.

> David, can you please have a look in jobclasses.h which signals must be 
> "public" (i.e. are intended for external use like e.g. undo) and which are 
> only for internal use and could be potentially replaced by direct calls, I 
> will do the rest if you agree.
I don't see signals that can be replaced with direct calls. Keep in mind that
in KIO there are subjobs and master jobs. The subjob emits a signal, the master
job connects to it, either for its own purpose (calculating progress) or for
calling a method in observer - or most of the case, both.

One unused signal from the slaves is gettingFile(), but it's already been 
removed from the main slaves (the ones in kdelibs). I'll clean the
kdebase ones.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2

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