D10857: Change qSort to std::sort in simplifiedUrlList

[David Faure]

dfaure accepted this revision.
dfaure added a comment.
This revision is now accepted and ready to land.


  " it does suck a little that qSort beats std::sort."
  I was curious whether that was true, so I ran Mark's benchmark, with a few fixes: one more zero in the number of items for the vectors, because there was too much variation in numbers when measuring something that lasts around 500ms, and I looped over the two sorting methods, to avoid having to run the benchmark multiple times (because I'm lazy, and because the first iteration seems to have some cold cache effect, the later ones are faster). http://www.davidfaure.fr/2018/qsort_performance.cpp
  
  That gives me pretty stable results.
  In release mode:
  
    "qSort took: 4710 ms"
    "std::sort took: 4818 ms"
    "qSort took: 4600 ms"
    "std::sort took: 4737 ms"
    "qSort took: 4610 ms"
    "std::sort took: 4739 ms"
    "qSort took: 4585 ms"
    "std::sort took: 4735 ms"
    "qSort took: 4592 ms"
    "std::sort took: 4748 ms"
    "qSort took: 4644 ms"
    "std::sort took: 4736 ms"
    "qSort took: 4605 ms"
    "std::sort took: 4767 ms"
  
  I ran both sorting algos (in RelWithDebInfo mode) in perf+hotspot to find out where the difference comes from, but I see nothing conclusive. std::sort goes via swap<QString,QString> which calls QString::swap(QString&) which calls qSwap(pointers) while qSort is able to call qSwap(pointers) directly, but that's all inline, shouldn't make a difference, I would expect. So it must be the sorting algorithm itself. Oh well, not much we can do, apart from, well, comparing libstdc++ and libc++, another day :)
  
  (Curiously, in debug mode, qSort is much slower than std::sort (9s vs 7.6s).)

REPOSITORY
  R241 KIO

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

To: jtamate, #frameworks, dfaure, markg
Cc: markg, apol, michaelh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180228/70abf42f/attachment.html>