[Development] QLog ( Work on qDebug and friends)

[BRM]

> From: Lincoln Ramsay <lincoln.ramsay at nokia.com>

>To: BRM <bm_witness at yahoo.com> 
>On 02/16/2012 02:14 AM, ext BRM wrote:
>>> This fails the "do nothing quickly" test so the cost of leaving
>>> such statements in shipping code is high, even when the categories
>>> are disabled.
>>> 
>>> This works fine though.
>>> 
>>> qLog(category1)<< "message for category1";
>>> qLog(category2)<< "message for category2";
>> 
>> No more than the Macro.
>> 
>> Yes, it would need to read all the strings; but then it could just
>> read them instead. The macro fails in the same respect.
>
>I don't think I get where you're going here.
>
>qLog expands to:
>
>if (do_nothing) /*NOP*/; else qDebug() << "your message";
>
>Why? Because the category check must be done first and it must be done quickly. That means things like no string operations in the "common" case (where we already know that the category is disabled). Sure, if you don't know if the category should be disabled you're going to have to do some calculations but that's the exception, not the norm.
>
>Filtering out either at the QDebug object level or the message handler level means that all of the code after the << _must_ be executed even if the resulting strings are going to be dropped on the floor. This could be hundreds of instructions which may not be noticeable on a desktop but will cripple any slower device.
>
>So...
>
>This code can quickly do nothing:
>qLog(category1) << "message for category1";
>qLog(category2) << "message for category2";
>
>This code cannot:
>qDebug() << category1 << "message for category1"
>         << category2 << "message for category2";
>
>Is the second syntax really that much better to justify the large performance hit? I just don't see it.


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.

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.

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.

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.


So, why not make the category actually mean something that _can_ be filtered if desired?

Ben