Hi,
during profiling YourKitProfiler always marks
org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
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
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
Hi
Created MYFACES-2538 Remove resourceVersion and libraryVersion from resource
identifiers.
regards,
Leonardo Uribe
2010/2/5 Leonardo Uribe lu4...@gmail.com
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
-hi,
has one checked what Trinidad is offering for that ?
I mean the code is pretty old (and therefore stable).
Also at Oracle there is quite some PREF testing done...
-Matthias
On Fri, Feb 5, 2010 at 5:38 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
Created MYFACES-2538 Remove
Hi
The code that serve resources on myfaces core comes from trinidad. There was
also other parts that comes from there too.
Leonardo Uribe
2010/2/5 Matthias Wessendorf mat...@apache.org
-hi,
has one checked what Trinidad is offering for that ?
I mean the code is pretty old (and therefore
Ah, ok :)
I am interested in what Martin comes up, regarding details.
Hopefully it is only getLibraryVersion(...) ;-)
-Matthias
On Fri, Feb 5, 2010 at 6:09 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
The code that serve resources on myfaces core comes from trinidad. There was
also other
I can confirm that problem was really in getLibraryVersion() - after few
hours of profiling (with simulation of 10 concurrent users) profiler
shows that JarEntry.nextElement() in was called over 300 000 000 times
(!) and getLibraryVersion() was total winner in cumulative time category
within
