[
https://issues.apache.org/jira/browse/JSPWIKI-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588901#action_12588901
]
Janne Jalkanen commented on JSPWIKI-50:
---------------------------------------
Yes, now that I was actually trying to merge this patch I saw these strangeness.
CachingProvider is caching different things in its caches, so having multiple
caches is fine (except that it has two caches for WikiPage objects, which is
strange).
Now, this patch introduces three interdependent caches for Attachment objects,
which to me sounds like way overhead, and dangerous, if these get out of sync.
The regular cache in the CachingAttachmentProvider caches a Collection of
Attachments per page (since one page can have multiple attachments), since
that's the usual calling pattern. But we could use OSCache's grouping ability
to optimize the cache in a better way - one group per page.
(NegCache stores page names which are known not to exist. This makes it fast
to test for existence of a page.)
> RecentChanges plugin is slow
> ----------------------------
>
> Key: JSPWIKI-50
> URL: https://issues.apache.org/jira/browse/JSPWIKI-50
> Project: JSPWiki
> Issue Type: Improvement
> Components: Plugins
> Reporter: Janne Jalkanen
> Assignee: Harry Metske
> Priority: Minor
> Fix For: 2.8
>
> Attachments: CachedAttachmentCollector.java,
> CachingAttachmentProvider.patch, PageTimeComparator.patch, Screenshot-20252
> msec -- -tmp-jip-profile.xml.png
>
>
> RecentChanges plugin gets awfully slow once the repository gets big enough.
> It might be a good idea to cache something or do some other performance
> optimizations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
