[jira] Issue Comment Edited: (WICKET-3511) Mapping ResourceReferences to Urls is slow

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005313#comment-13005313 ] 

Igor Vaynberg edited comment on WICKET-3511 at 3/10/11 8:26 PM:
----------------------------------------------------------------

im wondering why this isnt a problem in 1.4, maybe that already has caching in place that we lost with the rewrite of this portion of code. if you have time to research i would love to know the details.

      was (Author: ivaynberg):
    im wondering why this isnt a problem in 1.4, maybe that already has caching in place that we lost with in the rewrite of this portion of code. if you have time to research i would love to know the details.
  
> 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, 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