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/ _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development