<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/111050/">http://git.reviewboard.kde.org/r/111050/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On June 16th, 2013, 4:59 p.m. UTC, <b>Sven Brauch</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">While speedup is certainly always great, this sounds dangerous to me:

> I am getting an inconsistency. Using the unpatched fast mime detection on a file like: "test.tar.gz" gets detected as "application-x-compressed-tar" where the patched > version detects it as "application-gzip". The slow and detailed mime detection detects the same file as "application-x-compressed-tar". What should it be? > application-gzip or application-x-compressed-tar?
> Note: This improved detection does expect folders to end with a "/".

I have no idea how e.g. KDevelop would react to those changes. In any case I would vote against putting such a fundamental change in behaviour into the soon-to-be-released 4.11 (without a long testing period).

I didn't look at the code.</pre>
 </blockquote>







</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Hi Sven,

A "fundamental change in behaviour" .. It behaves exactly the same as it used to be.
"file:///home/yourusername/whateverforlder/" will be detected as folder. "file:///home/yourusername/whateverforlder" won't be detected as folder, but as the default.

However, even the file chooser popup dialog is now showing folders with "application-octet-stream" so i might have to revise the folder detection to be a bit more permissive.. Files seem to be just fine.</pre>
<br />










<p>- Mark</p>


<br />
<p>On June 16th, 2013, 4:42 p.m. UTC, Mark Gaiser wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for kdelibs, David Faure and Frank Reininghaus.</div>
<div>By Mark Gaiser.</div>


<p style="color: grey;"><i>Updated June 16, 2013, 4:42 p.m.</i></p>






<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Hi,

I've recently seen Frank Reininghaus do his best in speeding up the rendering in dolphin with regards to the app icons. And trying to prevent icon flickering between "unknown" and the actual icon.

While reading his posts on the mailing list i was beginning to wonder: "is fast mime detection actually fast"? While it was certainly faster then "slow" mime detection, it still didn't really seem fast to me. A small benchmark app hat ran fast mime detection in /usr/bin took ~40ms to complete. That's for just 2656 items.

After quite a bit of profiling i managed to to bring the duration down from ~40ms to ~3ms sometimes ~4ms. That's well over 10x faster.
Mime detection by extension (like "file.tar.bz") is done as follows:

file.tar.bz
Loop - find first dot
- "tar.gz"
if that matches a mime type then it's returned if it doesn't then it proceeds on to the next dot:
- next dot: "gz"
if that matches.. return.
Otherwise it will return the default mime type.

I am getting an inconsistency. Using the unpatched fast mime detection on a file like: "test.tar.gz" gets detected as "application-x-compressed-tar" where the patched version detects it as "application-gzip". The slow and detailed mime detection detects the same file as "application-x-compressed-tar". What should it be? application-gzip or application-x-compressed-tar?

Note: This improved detection does expect folders to end with a "/". Otherwise they will be detected as application-octet-stream (the default). But i think this is common sense to let folders end with a "/". If any apps that don't do that, they should fix it i suppose.

Best thing, it's all internal and private api change. No public function is changed.

All feedback is welcome! If possible, i would like to put this in KDE 4.11.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested this using just output comparison between the old version and the new implementation. It works just fine.</pre>
  </td>
 </tr>
</table>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>kdecore/services/kmimetype.h <span style="color: grey">(bc35bcf)</span></li>

 <li>kdecore/services/kmimetype.cpp <span style="color: grey">(d748523)</span></li>

 <li>kdecore/services/kmimetyperepository.cpp <span style="color: grey">(f56f48e)</span></li>

 <li>kdecore/services/kmimetyperepository_p.h <span style="color: grey">(e1d2389)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/111050/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>