AntPathMatcher creates many temporary objects [SPR-11258]

[spring-projects-issues]

Robert Gay opened SPR-11258 and commented

AntPathMatcher.doMatch appears to get called many times on each request, and it makes two calls to StringUtils.tokenizeToStringArray on each call. It looks like (but I'm admittedly not 100% sure) that at least some of the tokenizing work is being duplicated on every request, and could be precomputed at startup, or cached as it is used.

The two screenshots show the number of objects collected by the garbage collector during the loading of a single url and all associated AJAX requests (some of which result in multiple callbacks to the server). Both loads were primed once without the profiler running so that the difference between the caching version and the non-caching version would be clearer.

single-page-load-unmodified-spring.png shows the results running an unmodified version of Spring 3.1.4.RELEASE, the modified version incorporates the included patch file AntPathMatcher.java.patch.

The patch is pretty naive, and just throws everything into the same cache - I expect there's a better way to achieve a similar result.

I haven't directly tested this against 3.2.x or 4.0.x, but I did visually examine the AntPathMatcher.doMatch code and this part of it seems to have not changed since 3.1.4.

---

Affects: 3.1.4, 3.2.6, 4.0 GA

Attachments:

• AntPathMatcher.java.patch (2.25 kB)
• single-page-load-unmodified-spring.png (108.85 kB)
• single-page-modified-spring-core.png (100.78 kB)

Referenced from: commits ff26dfd

[spring-projects-issues]

Juergen Hoeller commented

I've added a cache for tokenized pattern parts to 4.0.1, driven by the same "cachePatterns" setting that also controls AntPathStringMatcher caching. This should cut the amount of temporary objects to half, caching a well-controlled set of path patterns as defined in the application.

Beyond that, caching the tokenization results of incoming paths is unfortunately a problem: The chances of the cache overflowing are high, due to arbitrary path permutations outside of the control of the application. For that reason, I haven't gone as far as caching those as well.

Juergen