Re: KFileItem optimization

Jakub Stachowski <[email protected]> Mon, 5 Jan 2009 22:55:51 +0100
Newsgroups gmane.comp.kde.devel.optimize
Message-ID <[email protected]>
--===============0402770469==
Content-Type: multipart/alternative;
  boundary="Boundary-00=_nHoYJa+P5IGmeFa"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-00=_nHoYJa+P5IGmeFa
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Dnia Monday 05 January 2009, David Faure napisa=C5=82:
> On Saturday 03 January 2009, Jakub Stachowski wrote:
> >  It is slow operation, because of mime-
> >
> > >is("application/x-desktop") check, which constructs KMimeType object f=
or
> >
> > application/x-desktop type again and again.
>
> Yep. I have on my todo list "optimizing KMimeType::is by adding a way in
> ksycoca to get a mimetype's parent without having to load it completely".
>
> > Attached patch adds fast path to
> > KMimeType::is by allowing to ignore resolving aliases. It is not a
> > problem in case of KFileItem, because application/x-desktop is not an
> > alias.
>
> Well, it is not at the moment, but who knows about the future?
> Any mimetype could be turned into an alias later on in order to solve some
> bug, like if we merge two mimetypes.
>
> Also, this is solving the wrong problem IMHO. Resolving aliases _is_ fast,
> since they are in a QMap in KMimeTypeFactory. The problem is just that
> findMimeTypeByName does both: resolving aliases _and_ loading the mimetyp=
e,
> which is the slow part. How about we resolve aliases without loading the
> mimetype? This would solve this in a much nicer way - no need for new API,
> the code would remain generic but just faster.
>
> Can you check the performance with this new patch?
> (This is orthogonal to my planned KMimeType::is() performance improvement
> which would make it even faster, btw).

Only slightly slower than my patch (~9% instead of ~7% CPU spent in=20
KFileItem::iconName()  ). But at least it is future-proof.


--Boundary-00=_nHoYJa+P5IGmeFa
Content-Type: text/html;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-=
html40/strict.dtd"><html><head><meta name=3D"qrichtext" content=3D"1" /><st=
yle type=3D"text/css">p, li { white-space: pre-wrap; }</style></head><body =
style=3D" font-family:'Sans Serif'; font-size:10pt; font-weight:400; font-s=
tyle:normal;">Dnia Monday 05 January 2009, David Faure napisa=C5=82:<br>
&gt; On Saturday 03 January 2009, Jakub Stachowski wrote:<br>
&gt; &gt;  It is slow operation, because of mime-<br>
&gt; &gt;<br>
&gt; &gt; &gt;is("application/x-desktop") check, which constructs KMimeType=
 object for<br>
&gt; &gt;<br>
&gt; &gt; application/x-desktop type again and again.<br>
&gt;<br>
&gt; Yep. I have on my todo list "optimizing KMimeType::is by adding a way =
in<br>
&gt; ksycoca to get a mimetype's parent without having to load it completel=
y".<br>
&gt;<br>
&gt; &gt; Attached patch adds fast path to<br>
&gt; &gt; KMimeType::is by allowing to ignore resolving aliases. It is not =
a<br>
&gt; &gt; problem in case of KFileItem, because application/x-desktop is no=
t an<br>
&gt; &gt; alias.<br>
&gt;<br>
&gt; Well, it is not at the moment, but who knows about the future?<br>
&gt; Any mimetype could be turned into an alias later on in order to solve =
some<br>
&gt; bug, like if we merge two mimetypes.<br>
&gt;<br>
&gt; Also, this is solving the wrong problem IMHO. Resolving aliases _is_ f=
ast,<br>
&gt; since they are in a QMap in KMimeTypeFactory. The problem is just that=
<br>
&gt; findMimeTypeByName does both: resolving aliases _and_ loading the mime=
type,<br>
&gt; which is the slow part. How about we resolve aliases without loading t=
he<br>
&gt; mimetype? This would solve this in a much nicer way - no need for new =
API,<br>
&gt; the code would remain generic but just faster.<br>
&gt;<br>
&gt; Can you check the performance with this new patch?<br>
&gt; (This is orthogonal to my planned KMimeType::is() performance improvem=
ent<br>
&gt; which would make it even faster, btw).<br>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0;"><br></p>Only slightly slower than my patch (~9% instead of ~7=
% CPU spent in KFileItem::iconName()  ). But at least it is future-proof.<b=
r>
<p style=3D"-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; ma=
rgin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-u=
ser-state:0;"><br></p></body></html>
--Boundary-00=_nHoYJa+P5IGmeFa--

--===============0402770469==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kde-optimize mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-optimize

--===============0402770469==--