Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of lu4242@gmail.com designates
 209.85.216.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=rCqwjnbBXJCaBUzJshZqeONerFM0jAX9SRs+qY52/PjZAPbf4eteIoBIH6J/gRUbJa
         eOYussZX/Su1E0GLoyeOyn5zh7Zi/362f24QeIu7CQZGy7ITocRnvz8BWgowljAQ2+wh
         NP+PeWFaFlYSsBxrVMN1Sm11S08Y2Ey6sU/pE=
MIME-Version: 1.0
In-Reply-To: <1265382390.4637.16.camel@markoc-desktop>
References: <1265382390.4637.16.camel@markoc-desktop>
Date: Fri, 5 Feb 2010 11:13:50 -0500
Message-ID: <f6c92361002050813m1c03d0c1xfabb344df09db123@mail.gmail.com>
Subject: Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String)
	performace
From: Leonardo Uribe <lu4242@gmail.com>
To: MyFaces Development <dev@myfaces.apache.org>
Content-Type: multipart/alternative; boundary=001636e0ba01adfe31047edcbc48

--001636e0ba01adfe31047edcbc48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi

Yes, that one is a big problem. There is no way to "traverse" a jar file
without iterating over all entries to get the library version and resource
version. That means the current algorithm do that all times a resource is
rendered. This is really bad.

I remember someone commented that on jsr-314-open at jcp.org mailing list,
and checking the latest ri code (2.0.2-b10), library and resource version
feature was removed. It seems a decision was taken there.

Checking more, the topic describing this is:

[jsr-314-open] Need guidance: invalid assumptions in design of resource
versioning feature

We should change our algorithm too to prevent this performance problem.

regards,

Leonardo Uribe

2010/2/5 Martin Koci <martin.koci@aura.cz>

> Hi,
>
> during  profiling YourKitProfiler always marks
> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(S=
tring)
> as hotspot - that method always takes 30--50% CPU time per one
> request/response. Is it a known problem? I will provide more information
> later.
>
> Regards,
>
> Martin Ko=C4=8D=C3=AD
>
>
>
>
>

--001636e0ba01adfe31047edcbc48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi<br><br>Yes, that one is a big problem. There is no way to &quot;traverse=
&quot; a jar file without iterating over all entries to get the library ver=
sion and resource version. That means the current algorithm do that all tim=
es a resource is rendered. This is really bad.<br>
<br>I remember someone commented that on jsr-314-open at <a href=3D"http://=
jcp.org">jcp.org</a> mailing list, and checking the latest ri code (2.0.2-b=
10), library and resource version feature was removed. It seems a decision =
was taken there.<br>
<br>Checking more, the topic describing this is:<br><br>[jsr-314-open] Need=
 guidance: invalid assumptions in design of resource versioning feature<br>=
<br>We should change our algorithm too to prevent this performance problem.=
<br>
<br>regards,<br><br>Leonardo Uribe<br><br><div class=3D"gmail_quote">2010/2=
/5 Martin Koci <span dir=3D"ltr">&lt;<a href=3D"mailto:martin.koci@aura.cz"=
>martin.koci@aura.cz</a>&gt;</span><br><blockquote class=3D"gmail_quote" st=
yle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex=
; padding-left: 1ex;">
Hi,<br>
<br>
during =C2=A0profiling YourKitProfiler always marks<br>
org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(Str=
ing) as hotspot - that method always takes 30--50% CPU time per one request=
/response. Is it a known problem? I will provide more information later.<br=
>

<br>
Regards,<br>
<br>
Martin Ko=C4=8D=C3=AD<br>
<br>
<br>
<br>
<br>
</blockquote></div><br>

--001636e0ba01adfe31047edcbc48--