[MAGNOLIA-7616] Optimizing ModuleBootstrapTask Created: 03/Sep/19  Updated: 16/Dec/21  Resolved: 13/Dec/21

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.7.4, 6.1.2
Fix Version/s: 6.2.15

Type: Bug Priority: Neutral
Reporter: Viet Nguyen Assignee: Nguyen Phung Chi
Resolution: Fixed Votes: 1
Labels: maintenance
Remaining Estimate: Not Specified
Time Spent: 1d 7h
Original Estimate: Not Specified

Attachments: PNG File image-2019-09-04-10-21-23-227.png    
Issue Links:
dependency
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Global Maintenance 3
Story Points: 3

 Description   

When profiling a test similar to ModuleVersionHandlerTestCase, it turns out that ModuleBootstrapTask.accept() results in 60 million String.append() operations.
That's because ModuleBootstrapTask.accept() is called number of modules times number of files in all JAR files, resulting in 20 million invocations.
A simple optimization brought execution time for our test down from 110s to 60s, only by caching the result of the String operation. Any Magnolia startup with empty repository should profit similarly from this optimizaton. Please find attached the optimized class.

Please consider an improvement here.



 Comments   
Comment by Joerg von Frantzius [ 04/Sep/19 ]

Evidence from JProfiler on startup of Magnolia DX:

Comment by Richard Gange [ 23/Nov/21 ]

See https://jira.magnolia-cms.com/secure/attachment/57587/ModuleBootstrapTask.java

Generated at Mon Feb 12 04:25:20 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.