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
            Reporter: Matt Brictson
         Attachments: CachingResourceStreamLocator.java

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 300 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 300 ms to 
30 ms.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to