[Development] QLog ( Work on qDebug and friends)

[Lincoln Ramsay]

On 02/16/2012 04:16 PM, ext BRM wrote:
> Unless you're operating on a very slow processor (which is unlikely
> nowadays) or in a very highly time-sensitive environment (again,
> unlikely, or you probably wouldn't be using Qt anyway, and you'd
> probably be running QNX, VxWorks, or rtLinux in such case too), then
> the performance overhead won't be that great for doing the filtering
> on the fly.

Perhaps... though there are many devices that have single-core, sub-Ghz 
CPUs and that's not going to change for a while yet. Plus, it will 
always be beneficial to use as few cycles as possible on a mobile device 
to extend battery life.

> As I noted earlier, I do deal with a system that is in
> near-real-time, collecting and processing data at up to 400HZ. It
> runs Linux with Qt; and does extensive logging in real-time to
> syslog.  When errors occur, 500MB of logs can be accumulated in a few
> seconds. Yet the logging is a not performance issue. So I fail to see
> the need to be so performance sensitive about the logging.

It's one thing to put logs into your own system. If they were a 
performance problem, you'd be able to do something about it. It's quite 
another thing to find out that a third party library you use has put in 
a bunch of logging statements that are wasting CPU doing nothing. Since 
the point of putting qLog into QtCore is to add a bunch of logging 
statements to Qt itself, it's pretty important that the overhead of 
those statements is as low as possible until they are turned on.

> As you're already changing to use qLog() vs qDebug() - you can just
> as easily disable it by having qLog() do the same thing :
>
> #define qLog() if (do_nothing); else qDebug()<<  category1<<"message
> for category 1"<<  category2<<"message for category2";
>
> And you get the benefit of being able to push more than one category
> through a single call. You're macro is not filtering based on the
> cateogry - it's not doing _anything_ with the category.

Er... I've been using a generalized form of the macro for example 
purposes. The real one most certainly does filter based on the category. 
If you care about the implementation details, see the change:
http://codereview.qt-project.org/#change,13226

> Furthermore, if you do make the macro evaluate the category, then you
> have to call something at run-time to do the filtering, in which case
> what I propose is equally as good.

No, for the reasons stated before and above. Moving the "filtering" down 
into the QDebug object or message handler results in a lot of work to 
generate messages that get thrown away.

-- 
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/