[PATCH] Re: [PATCH] Speeding up kdebug

[Roger Larsson]

On Wednesday 15 October 2003 02.02, Nicolas Goutte wrote:
> Optimizing kdbgstream could be interesting, especially as the boolean print
> is already there.

Yes, I tought of that too...
But code is better than words - but you are too quick...
So it is only compiled, not tested...

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

Yes.

>
> 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.

I have not modified this part.

/RogerL

>
> 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 :)
> (...)

-- 
Roger Larsson
Skellefteå
Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdebug.patch
Type: text/x-diff
Size: 10915 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031015/eed1aba2/attachment.patch>