D13652: Speed up LFtoCRLF by 20% by not scanning all of it for \r\n.

[David Faure]

dfaure created this revision.
dfaure added a reviewer: KDE PIM.
Restricted Application added a project: KDE PIM.
Restricted Application added a subscriber: kde-pim.
dfaure requested review of this revision.

REVISION SUMMARY
  The concept of "if it contains \r\n somewhere, don't do anything"
  already assumed that the input string was consistent in terms of
  newlines. So we can use this to our advantage and only check the first
  newline rather than scanning the whole message. Of course this leads to
  a different result in some pathological cases like \n on the first line
  and \r\n somewhere later, but the assumption is that this can't happen,
  right?
  
  Includes a unittest for LFtoCRLF and CRLFtoLF, and a
  benchmark for LFtoCRLF.
  
  $ bin/utiltest -perf -iterations 5000
  
  Before:
  RESULT : UtilTest::testLFCRLF_performance():
  
    276,538.3707 CPU cycles per iteration
    0.0790 msecs per iteration
  
  After:
  RESULT : UtilTest::testLFCRLF_performance():
  
    218,439.8416 CPU cycles per iteration
    0.0632 msecs per iteration
  
  The relevance of all this is that I found that 6% of the time was spent
  in LFtoCRLF when parsing a very big email in kmail (caveat:
  non-optimized build, unlike the above benchmark).

TEST PLAN
  Tested for a few days with an additional Q_ASSERT(!s.contains("\r\n"));
  to see if it would happen that a mail would start with \n and have \r\n later on,
  didn't happen (which is no proof of course).

REPOSITORY
  R180 PIM: KMime

BRANCH
  Applications/18.04

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

AFFECTED FILES
  autotests/utiltest.cpp
  autotests/utiltest.h
  src/kmime_util.cpp

To: dfaure, #kde_pim
Cc: kde-pim, #kde_pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180621/5d2c91a9/attachment.html>