From: Sebastian M. <ma...@sm...> - 2010-01-06 20:16:27
|
Gabriel M. Beddingfield wrote: > Hi Sebastian, > > On Tue, 5 Jan 2010, Sebastian Moors wrote: > > >> I've just read all the other mails concerning the logger class and a few >> questions popped out of mind.. >> If i understand it correct, the new proposal uses something like >> INFOLOG( const char* , .. ) instead of INFOLOG( const QString ). Why is >> this faster? Is it just the fact the we don't have to pass the QString >> by value, which results in an expensive call to the copy constructor ? >> > Correct on the change to INFOLOG. > > The objective isn't to be /faster/, but to be real-time > safe. QString::QString(...) and QString::operator=(const > QString&) are not real-time safe because they allocate > memory dynamically (i.e. they use 'new'). You must not do > this in a real-time thread. > > We currently work around this by wrapping the code inside an > integer check. Something like: > > if( Logger::log_level()& Logger::Info ) { > Logger::log(Logger::Info, message, ... ); > } > > This avoids invoking QString's methods unless the logging > level is set sufficiently high. > > But if you /do/ set the log level high, you risk becoming a > JACK zombie while you wait on `new QChar`. > > The proposal would use strings that are allocated on the > stack or pre-allocated in a buffer. > > As a side benefit, these strings will also run faster > becaus. However, you give up the benefits of having unicode > strings. > Thanks, your explanation of the allocation problem made it clear! - Sebastian |