Le 30/09/2014 14:15, Konstantin Kolinko a écrit : > AFAIK jars from JIRA web application were used for the test. From > comment on commit that removed the cache, the difference was 10-15%, > for our copy of BCEL that already had other optimizations (code > removal) applied:
I ran the PerformanceTest class applied on the rt.jar file from Java 8. For ClassParser.parse() I get 1300ms when the cache is enabled, and 820ms without (~37% faster). Using a HashMap instead of a LinkedHashMap is slightly faster (1200ms) but the cache entries are no longer evicted automatically. On the memory side, the benefit of the cache was more perceptible. Parsing rt.jar created ~10MB of ConstantUtf8 instances with the cache enabled, and 27MB without. At the end the cache retained 20000 instances for a total of ~450KB and there is no way to clear it. If nobody object I'll remove this cache, the impact on the performance is too important to enable it by default, and the static state smells like a quick and dirty implementation. This feature could return as a pluggable cache if someone wants to provide a patch. Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
