You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Csaba Varga (Jira)" <ji...@apache.org> on 2024/03/11 15:04:00 UTC

[jira] [Commented] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type

    [ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825350#comment-17825350 ] 

Csaba Varga commented on SLING-12265:
-------------------------------------

I have already made some experimental changes on this today, and my unit tests complete noticeably faster with my tentative improvement. I will open a PR today or tomorrow with the proposed changes.

> Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
> --------------------------------------------------------------------------------------------
>
>                 Key: SLING-12265
>                 URL: https://issues.apache.org/jira/browse/SLING-12265
>             Project: Sling
>          Issue Type: Improvement
>          Components: Testing
>    Affects Versions: Testing Sling Mock 3.4.18
>            Reporter: Csaba Varga
>            Priority: Minor
>              Labels: performance
>
> I did some profiling on my company's slow-running unit tests today, and found that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more specifically in the commit() call triggered by it. Our test classpath includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being detected, and as many commits done preparing the repository before each test. (Slightly more, because some commits fail and get retried later.)
> It should be possible to parse each CND into memory structures in a separate pass, then create the node types all at once in a single commit. This wouldn't just eliminate the extra commits, but would also remove the need to retry, since all dependencies would also be provided in the same call.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)