[
https://issues.apache.org/jira/browse/TOMEE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated TOMEE-4662:
-------------------------------------
Description:
Speed up annotation processing during WAR deploy
OpenEJBContextConfig.isIncluded() resolves the canonical path of the module
roots and of the web resource on every call, and Tomcat calls
processAnnotationsWebResource() once per web resource. On a WAR with a few
hundred classes under WEB-INF/classes that is thousands of filesystem
syscalls, most of them resolving the same handful of paths again and again.
Three changes, no behaviour change:
Memoise File.getCanonicalFile() and the URL to File conversion. Both
mappings are stable for the lifetime of a deploy and the config instance is
per context.
Return early from processAnnotationsWebResource() once every module has
been processed. There is nothing left to match the resource against, and
that
branch never delegates to super, so resolving the resource is wasted work.
Reuse the path from FileResource.getCanonicalPath() instead of letting
isIncluded() resolve the same, already canonical, path a second time.
Measured on a synthetic WAR (40 jars, 513 classes in WEB-INF/classes) with
tomee-embedded: isIncluded() accounted for 165 of 468 deploy-phase profiler
samples before the change and 1 after, and deploy wall time dropped ~25%.
Note this was measured on Windows, where getCanonicalPath() is considerably
more expensive than on Linux, so expect a smaller gain there.
Also see apache/tomcat#1030
> Speed up annotation processing during WAR deploy
> ------------------------------------------------
>
> Key: TOMEE-4662
> URL: https://issues.apache.org/jira/browse/TOMEE-4662
> Project: TomEE
> Issue Type: Improvement
> Reporter: Thomas Andraschko
> Priority: Major
>
> Speed up annotation processing during WAR deploy
> OpenEJBContextConfig.isIncluded() resolves the canonical path of the module
> roots and of the web resource on every call, and Tomcat calls
> processAnnotationsWebResource() once per web resource. On a WAR with a few
> hundred classes under WEB-INF/classes that is thousands of filesystem
> syscalls, most of them resolving the same handful of paths again and again.
> Three changes, no behaviour change:
> Memoise File.getCanonicalFile() and the URL to File conversion. Both
> mappings are stable for the lifetime of a deploy and the config instance
> is
> per context.
> Return early from processAnnotationsWebResource() once every module has
> been processed. There is nothing left to match the resource against, and
> that
> branch never delegates to super, so resolving the resource is wasted work.
> Reuse the path from FileResource.getCanonicalPath() instead of letting
> isIncluded() resolve the same, already canonical, path a second time.
> Measured on a synthetic WAR (40 jars, 513 classes in WEB-INF/classes) with
> tomee-embedded: isIncluded() accounted for 165 of 468 deploy-phase
> profiler
> samples before the change and 1 after, and deploy wall time dropped ~25%.
> Note this was measured on Windows, where getCanonicalPath() is
> considerably
> more expensive than on Linux, so expect a smaller gain there.
> Also see apache/tomcat#1030
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
