[Development] QLog ( Work on qDebug and friends)
lincoln.ramsay at nokia.com
Thu Feb 16 10:00:31 CET 2012
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:
> 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/
More information about the Development