<table><tr><td style="">dfaure created this revision.<br />dfaure added a reviewer: KDE PIM.<br />Restricted Application added a project: KDE PIM.<br />Restricted Application added a subscriber: kde-pim.<br />dfaure requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D13652">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>The concept of "if it contains \r\n somewhere, don't do anything"<br />
already assumed that the input string was consistent in terms of<br />
newlines. So we can use this to our advantage and only check the first<br />
newline rather than scanning the whole message. Of course this leads to<br />
a different result in some pathological cases like \n on the first line<br />
and \r\n somewhere later, but the assumption is that this can't happen,<br />
right?</p>

<p>Includes a unittest for LFtoCRLF and CRLFtoLF, and a<br />
benchmark for LFtoCRLF.</p>

<p>$ bin/utiltest -perf -iterations 5000</p>

<p>Before:<br />
RESULT : UtilTest::testLFCRLF_performance():</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">276,538.3707 CPU cycles per iteration
0.0790 msecs per iteration</pre></div>

<p>After:<br />
RESULT : UtilTest::testLFCRLF_performance():</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">218,439.8416 CPU cycles per iteration
0.0632 msecs per iteration</pre></div>

<p>The relevance of all this is that I found that 6% of the time was spent<br />
in LFtoCRLF when parsing a very big email in kmail (caveat:<br />
non-optimized build, unlike the above benchmark).</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Tested for a few days with an additional Q_ASSERT(!s.contains("\r\n"));<br />
to see if it would happen that a mail would start with \n and have \r\n later on,<br />
didn't happen (which is no proof of course).</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R180 PIM: KMime</div></div></div><br /><div><strong>BRANCH</strong><div><div>Applications/18.04</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D13652">https://phabricator.kde.org/D13652</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>autotests/utiltest.cpp<br />
autotests/utiltest.h<br />
src/kmime_util.cpp</div></div></div><br /><div><strong>To: </strong>dfaure, KDE PIM<br /><strong>Cc: </strong>kde-pim, KDE PIM, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>