Why don't you use in Qt "Critical Sections" (Windows and Mac). They work great and fast, and do the same as QMutex.
Philippe On Tue, 17 Feb 2009 09:20:09 +0100, Bradley T. Hughes <[email protected]> wrote: > Martin Dyde wrote: >> Hello Qt team, >> I'd been seeing a drop in performance when moving from Qt 4.4.3 to Qt >> 4.5, and I've tracked it down to a change implemented in Qt 4.5's >> QMutex::lock() fn, in which you've added a new 'mutex spinning' >> mechanism which repeatedly re-tries to get the lock from the OS, rather >> than just waiting on it. This causes approximately a 25 percent drop >> in overall application performance (polyphony) in our case, i.e. a very >> significant and measurable degredation. > > Ouch... that's not good :/ All of my tests showed that the short spin > actually improved performance under contention, but obviously I can't > test everything. Are the mutexes in your application highly contented, > or mostly unused? > >> If I manually remove the new spin code from the Qt src, so that >> QMutex::lock() behaves the same as it did in Qt 4.4.3, then all is well >> again and we get that 25 percent of performance back. > > Would you consider trying to tune the constants to see if there's some > middle ground to be found? For example, what about: > > enum { AdditionalSpins = 10, SpinCountPenalizationDivisor = 10 }; > > ? > >> I appreciate that there might be some cases where the spinning >> mechanims could give improved performance, but for our type of >> application it's very definitely (and measurably) much worse. > > And a performance regression is definitely something we can't have... > >> Since we have a work-around for it (a custom edit to the Qt src to take >> out the spin functionality), it isn't a high priority for us, but my >> request would be for the longer term that you could make the spin >> functionality optional - perhaps a new QMutex property to avoid having >> the overhead of having to to pass an extra bool to QMutex::lock() or >> QMutexLocker with each call? Or, probably better still, a >> precompiler/configure option to avoid the spin code (and also avoid a >> runtime condition) altogether? > > That we could do, but honestly I'd probably just end up removing the > spinning if it doesn't work the way it was intended (which was to > improve through-put for highly contended mutexes that are held for short > amounts of time). > >> Many thanks and best regards, >> Martin Dyde, >> Milan Digital Audio LLC. >> http://www.crumhorn-labs.com/ >> http://www.milandigitalaudio.com/ >> > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
