mirror of
https://github.com/spring-projects/spring-boot.git
synced 2026-09-30 06:09:14 +00:00
DongHoon Lee
5c2ad14f50
ClassLoaderFilesResourcePatternResolver.isDeleted() calls resource.exists() and resource.getURI() inside the loop over the uploaded files, so both are repeated once per DELETED entry although neither depends on the entry. Every resource lookup made while the application context is being built goes through this method - about 1300 times per restart in the application I measured - so a session that has accumulated 100 deleted files performs around 130 000 file system lookups where 1300 are enough. This commit hoists both calls out of the loop: the resource is inspected at most once per call, on the first DELETED entry, and the URI comparison then uses the cached value. The method still returns on the first match and still reports a failing getURI() as an IllegalStateException, so behaviour is unchanged. The loop now walks the per-directory entry sets, which is what ClassLoaderFiles.addAll() and RestartServer already do, instead of the flattened view added in gh-46289. That view is wrapped in Collections.unmodifiableSet(), whose iterator is shared JDK code; in a running application its delegate calls are megamorphic and C2 stops inlining them, which made restarts with many accumulated files and no deletions slower than before gh-46289. isDeleted() returns a boolean, so the visiting order of the entries cannot change its result. Measured on a Spring Boot application driven through the remote restart path (restart request to ApplicationReadyEvent), 12 JVMs per variant and 20 restarts per JVM, medians: 100 source directories, 10 000 entries, 10 deleted: 278 ms -> 200 ms 100 source directories, 10 000 entries, 100 deleted: 891 ms -> 201 ms 100 source directories, 10 000 entries, 500 deleted: 3536 ms -> 200 ms 100 source directories, 50 000 entries, none deleted: 431 ms -> 341 ms 100 source directories, 10 000 entries, none deleted: 202 ms -> 192 ms no uploaded files: 150 ms -> 148 ms See gh-51841 Signed-off-by: DongHoon Lee <dhl1924@naver.com>