On Saturday 19 May 2012 07:30:56 lars.kn...@nokia.com wrote: > A few comments from my side: > > * I am not a big fan of inlining the public classes neither. It feels a > bit like over-optimizing at the wrong place. Reason is that this might > make it a impossible later on to refactor our code.
In general, I agree. (This is why I was againt the fact that the new QMetaType API is inline) But in this case, we are talking about very little specially crafted instructions, on a critical path. Nothink compared to the complexity of, say, QString or QVector. The instructions are made so that any unexpected value will fallback to non inline code. > * It's ok to have some low level inline class for internal use if that > helps us in performance critical parts (such as signal/slot code). Nothing > says this and the public QMutex class have to be the same. QBasicMutex it is internal. (but is still used directly by QMutex) > * IMO we should really try to allow using tools such as helgrind also with > release build This would indeed ease the use case of developper who are developping against packaged version of Qt. But I beleive they should still get a debug version of Qt, because the debug version offer much more ASSERT and qWarning that are stripped out of a release version. > * it would be good to see how much of a real world (ie. not with > artificial benchmarks) difference you get due to inlining the mutex code. > Is it really relevant? I agree with that. One needs to run benchmark :-) -- Olivier Woboq - Qt services and support - http://woboq.com _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
