For Windows, I am sure QMutex wins (with Visual Studio 2017). Not only I got much better figures, but tracing the assembly code of QMutex vs std::mutex shows you why QMutex is better. Easy to check. In release mode of course.
Philippe On Wed, 29 May 2019 20:12:05 +0200 Mikhail Svetkin <mikhail.svet...@gmail.com> wrote: > The implementation of QMutex, and especially QReadWrtieLock is much more > efficient that one of most standard library. > > > > I have run some benchmarks recently and the result did not show the QMutex > was the best. > I published the results here: > > - > https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444244&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444244 > - > https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444654&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444654 > > > > > Best regards, > Mikhail > > > > > > > On Wed, 29 May 2019 at 19:44, Kevin Kofler <kevin.kof...@chello.at> wrote: > > Mutz, Marc via Development wrote: >> > == QSharedDataPointer / QExplicitlySharedDataPointer == >> > >> > These are basically Qt-internals, and should never have been public in >> > the first place. >> >> Why? They are essential to be able to implement one's own CoW types and thus >> write idiomatic Qt code. >> >> I use QSharedDataPointer a lot, and my code will likely be stuck on Qt 5 or >> 6 forever if they get removed resp. deprecated in Qt 6. >> >> > == Q_FOREACH -> ranged for loops >> > (https://codereview.qt-project.org/c/qt/qtbase/+/147363) == >> >> As I already wrote when Q_FOREACH was deprecated to begin with, the problem >> is that this replacement is dangerous because ranged for does not copy (so >> legacy code that accidentally changed the container, which was harmless with >> Q_FOREACH, will crash and burn with ranged for) and can be inefficient with >> CoW types if done carelessly because ranged for does not automatically >> constify the container (whereas Q_FOREACH made a const copy). >> >> > === related: Q_FOREVER -> for(;;) === >> >> This just reduces readability for no maintainability gain whatsoever. >> >> > == Java-style iteration >> > (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == >> >> The Java-style iterators are much more convenient to use than the STL-style >> ones, and quadratic loops can be accidentally written with both. >> >> > == QScopedPointer -> std::unique_ptr == >> > == QLinkedList -> std::list >> > == qHash() -> std::hash == >> > == MT plumbing == >> > === QAtomic -> std::atomic === >> > === QMutex / QReadWriteLock -> std::*mutex* === >> > === QMutexLocker -> std::unique_lock === >> > === QWaitCondition -> std::condition_variable(_any) === >> > == QQueue / QStack -> std::queue, std::stack == >> > == QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr == >> > == QSet / QHash -> std::unordered_set/map == >> > == QMap -> std::map == >> >> All these have the same issue: You are proposing to deprecate Qt types in >> favor of STL types, which have a different naming convention (_ vs. camel >> case) and often terse, harder to understand names (e.g., ptr vs. Pointer, >> push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support >> CoW (all the container types in your list), nor Java-style iterators, for >> that matter. >> >> I think Qt should keep striving for completeness and not require its users >> to mix&match Qt and STL usage with all the STL's ugliness. >> >> Kevin Kofler >> (who thinks C++ is a great language except for its standard library) >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
