[PATCH] Speeding up kdebug

[Nicolas Goutte]

Optimizing kdbgstream could be interesting, especially as the boolean print is 
already there.

However for doing it in KDE 3.2, there is the problem that the constructors 
are all inlined, so you cannot modify them. (BIC!)

On the other side, as kdbgstream is always called by kdDebug, kdWarning, 
kdError and kdFatal, may be you can call here the function which will unset 
the boolean print if it should not be printed.

As for reading the file kdebug.areas, I have chosen Dirk Mueller's idea, as it 
does not disturb kdebugdialog. It can be optimized even more if we test for 
NUL and if we do not use QCString::length (which is slow.) And in KDE4, we 
could then discuss if the file kdebug.areas should stay or not.

Have a nice day!

--- Original Message ---
List:     kde-core-devel
Subject:  Re: [PATCH] Speeding up kdebug
From:     David Faure <faure () kde ! org>
Date:     2003-10-14 22:23:19

On Tuesday 14 October 2003 23:07, Nicolas Goutte wrote:
> No, it is not one-time only or we would have not had this big kdebug 
> discussion for just one entry in kdebug.areas. (I have counted 60 calls in 
my 
> .X.err for one hour of up-time. I do not know if it is typical or not.)

It is one time, *per process*.
Of course in your .X.err it appears several times, since you launch several
processes.

Another idea I had today about speeding up kdDebug was whether it would
gain anything to check that we're going to print out anything, in the 
constructor
of kdbgstream, to skip all the string concatenation if we're going to eat the
debug output anyway. This might speed up KAccel/KAction stuff since by default
125/129 are disabled, and this is called very often. At the moment it's 
kDebugBackend,
called during flushing, which determines whether the printing is enabled or 
not.

Anyway - this speeds things up for developers only. End users get all this
optimized out. I just want to prevent misunderstandings here :)
(...)