D13814: Speedup sort

[Stefan Brüns]

bruns added a comment.


  In D13814#290556 <https://phabricator.kde.org/D13814#290556>, @markg wrote:
  
  > Is there even a need to have n QCollator objects?
  >  I'm talking about a QCollator _within_ a given view. Each view could obviously have it's own collator due to different view settings.
  
  
  Strictly speaking you need one collator per thread (it is reentrant (save the bug), but not thread-safe). As long as the collator objects are not modified, each one is just the d-pointer, as QCollator is CoW.
  
  Copying a clean QCollator is cheap. Default-constructing one and modifying it is expensive - each one has to be initialize the underlying ICU (actually, this happens twice for each one, once on construction, once after the m_collator.setFoo(...) calls).
  
  Using a const reference, as done here, is even slightly cheaper. But doing so is also undefined behaviour - QCollator is reentrant, but not thread-safe. We get away with it by using the forced initialization, which avoids the UB (UB only happens when the QCollator is dirty).
  
  When the fix in https://codereview.qt-project.org/#/c/234359/3//ALL,unified is applied, it is no longer necessary to force the `init()` under the premise each thread uses its own private collator object (which is implicitly shared).

REPOSITORY
  R318 Dolphin

REVISION DETAIL
  https://phabricator.kde.org/D13814

To: jtamate, #dolphin, #frameworks, markg, elvisangelaccio, bruns
Cc: elvisangelaccio, apol, bruns, markg, kfm-devel, spoorun, navarromorales, firef, andrebarros, emmanuelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180712/d0ee9b68/attachment.html>