Improve performance of case-sensitive file key checking #165
Conversation
…er version once during class initialization
# Conflicts: # doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
|
@jdimeo Very nice. Can you file a JIRA issue as well, I'd be happy to review this. |
doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Outdated
Show resolved
Hide resolved
|
@jdimeo what us your opinion on the OS check? Should it be extended to macOS as well? HFS+ and APFS are case-insensitive by default. |
|
@jdimeo Please don't forget to rebase. I cannot be merged at this stage. |
|
I'm struggling to do that because apparently a huge number of formatting changes are creating a merge conflict where it's difficult to tell if my commit is being preserved. I tried running the Spotless plugin with the latst pom.xml from master, but it didn't reformat. |
|
I think the problem relates to me using my existing fork from awhile ago and so the rebase is starting with a very very old version. |
|
OK I totally started over. Please see: #170 |
Our Maven site now has about 150,000 Doxia files to render (mostly Markdown and some ASCII doc). During profiling, I realized the Maven site plugin was spending around 18 minutes in the
addModuleFiles()method. When looking at the code, I realized the algorithm was O(n² - n / 2) the way it adds each file it discovers to a map and the iterates through the map for each file.This approach uses a secondary hash map to achieve O(2n) instead to check for a case-insensitive duplicate file to error on Windows and warn on other OSes.