Philippe wrote: > Why don't you use in Qt "Critical Sections" (Windows and Mac). They work > great and fast, and do the same as QMutex.
Qt doesn't have a critical section object, only 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/ >>> >> >> > > > -- Bradley T. Hughes (Nokia-D-Qt/Oslo), bradley.hughes at nokia.com Sandakervn. 116, P.O. Box 4332 Nydalen, 0402 Oslo, Norway _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
