[
https://issues.apache.org/jira/browse/WICKET-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004766#comment-13004766
]
Matt Brictson commented on WICKET-3511:
---------------------------------------
Martin, I don't think your latest patch accomplishes what I was originally
setting out to do with the cache. The most time consuming operations are the
multiple calls that PackageResourceReference makes to locate(Class<?>, String,
String, String, Locale, String, boolean). For the sake of discussion let's call
that method "complex locate". By subclassing ResourceStreamLocator and
overriding the simpler locate(Class<?>, String) (let's call it "simple locate",
we are taking advantage of the fact that ResourceStreamLocate internally
delegates to the simple locate method in order to implement the complex one.
So for example, calling the complex locate may internally involve many calls to
the simple locate. By overriding the simple locate and putting caching there,
we therefore get caching for both methods.
However this approach (that is, putting caching on just the simple locate())
will not work as a decorator pattern. Therefore the decorator needs to
implement caching for both the simple and complex locate method in order to be
effective.
> Mapping ResourceReferences to Urls is slow
> ------------------------------------------
>
> Key: WICKET-3511
> URL: https://issues.apache.org/jira/browse/WICKET-3511
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC2
> Reporter: Matt Brictson
> Assignee: Martin Grigorov
> Attachments: CachingResourceStreamLocator.java, WICKET-3511.patch,
> WICKET-3511.patch
>
>
> PackageResourceReference is often used for stylesheets and JavaScript
> resources, many of which can appear on a typical page (WicketAjaxReference is
> one common example). Every time the page is rendered, these resources are
> mapped to urls in order to build the appropriate <link href="..."> or <script
> src="..."> tags.
> The trouble is that this mapping process is extremely inefficient. To map a
> ResourceReference to a url, ResourceReference#getLastModified() must be
> consulted for FilenameWithTimestampResourceCachingStrategy, and
> ResourceReference#getUrlAttributes() is called to append appropriate query
> parameters.
> In PackageResourceReference, both of these methods delegate to the very
> expensive PackageResourceReference#lookupStream(), which makes several
> attempts to locate the underlying file or classpath item using various
> permutations of locale, style, and variation. Each of these attempts involves
> I/O. The default ResourceStreamLocator, which does the actual file and
> classpath queries, does no caching whatsoever.
> On a trivial Wicket page containing 7 total PackageResourceReferences for
> images, stylesheets and JavaScript files, the average response time in my
> tests was 211 ms. The vast majority of that time was spent in
> ResourceStreamLocator, due to the expensive steps described above.
> It seems that putting caching at the ResourceStreamLocator would be extremely
> beneficial. I am attaching a simple implementation. With caching enabled in
> ResourceStreamLocator, the response time of my test page dropped from 211 ms
> to 49 ms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
