I have ported a complex multitasked application to Qt, and I have replaced all Critical Sections with Qt mutextes. This works, no bug, but with a decrease of performance under stressed situations. This is why I do say QMutex could use the native critical section API as implementation.
Philippe On Tue, 17 Feb 2009 11:04:46 +0100, Bradley T. Hughes <[email protected]> wrote: > 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/ >>>> >>> >>> >> > > -- 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
