Skip to content

Perfomance issue on module init for big apps caused by registerNgModuleType function. #39487

Closed

Description

@proofyman

🐞 bug report

Affected Package

The issue is caused by package @angular/core

Is this a regression?

Don't know, seems like not.

Description

We have a big application with deep imports tree. There is function registerNgModuleType, that slow down application, depends on import count.

Problem is that its not depend on unique imports, just all imports, for every tree node down to leaf.

Function does nothing ( mb do something in compile time according to comment ), because it register modules, if them have ids. Modules in our app doesnt have them, no single module have id.

So function, that do nothing, slow down perfomance by 2 seconds for chrome, and 10s for ie11 on my pc. I just delete this function, and perfomance now is ok, and application fully workable.

🔬 Minimal Reproduction

Sorry, i cant add reproduction, because its requires enormous quantity of modules. I could generate them, if needed, but code clear enought to see the problem.

Anything else relevant?
Perfomance on navigation. All green fn blocks - registerNgModuleType and nested fns. There are a lot of calls, about 10k, i dont know. Each call takes 0.1ms, but all of them take 2s and do nothing.
image

Activity

  1. changed the title [-]Perfomance issue on module init for big apps caused by noop function.[/-] [+]Perfomance issue on module init for big apps caused by registerNgModuleType function.[/+] on Oct 29, 2020
  2. added this to the needsTriage milestone on Oct 29, 2020
  3. added
    P3An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
    on Oct 30, 2020
  4. modified the milestones: needsTriage, Backlog on Oct 30, 2020
  5. JoostK commented on Oct 30, 2020

    @JoostK
    Member

    Hello @proofyman, thanks for reporting!

    Could you check for me what the performance characteristics are when you replace registerNgModuleType with the following implementation:

    export function registerNgModuleType(ngModuleType) {
        recurse(ngModuleType, new Set());
        function recurse(ngModuleType, visited) {
            const def = ngModuleType.ɵmod;
            const id = def.id;
            if (id !== null) {
                const existing = modules.get(id);
                assertSameOrNotExisting(id, existing, ngModuleType);
                modules.set(id, ngModuleType);
            }
            let imports = def.imports;
            if (imports instanceof Function) {
                imports = imports();
            }
            if (imports) {
                for (const i of imports) {
                    if (!visited.has(i)) {
                        visited.add(i);
                        recurse(i, visited);
                    }
                }
            }
        }
    }

    That should avoid traversing into NgModule import graphs that have already been visited.

  6. proofyman commented on Oct 30, 2020

    @proofyman
    Author

    I tested your code, cant find it in perfomance chart, so its good enough =). Ie11 working nice, chrome too.

    But why you just do not remove this code in runtime ? As i can see modern angular doesnt use module ids.

  7. JoostK commented on Oct 30, 2020

    @JoostK
    Member

    I tested your code, cant find it in perfomance chart, so its good enough =). Ie11 working nice, chrome too.

    Excellent, thank you for confirming! In that case I opened #39514 to make the necessary changes.

    But why you just do not remove this code in runtime ? As i can see modern angular doesnt use module ids.

    I believe there is still uses of module ids in the wild, so it can't be removed right away. In the future it may become possible to remove the surrounding API (getModuleFactory) which should indeed allow this registration business to be removed.

  8. added a commit that references this issue on Oct 30, 2020
    dfaf450
  9. added 2 commits that reference this issue on Nov 2, 2020
    812355c
    5c13c67
  10. angular-automatic-lock-bot commented on Dec 3, 2020

    @angular-automatic-lock-bot

    This issue has been automatically locked due to inactivity.
    Please file a new issue if you are encountering a similar or related problem.

    Read more about our automatic conversation locking policy.

    This action has been performed automatically by a bot.

  11. locked and limited conversation to collaborators on Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3An issue that is relevant to core functions, but does not impede progress. Important, but not urgentarea: coreIssues related to the framework runtimearea: performanceIssues related to performancecore: performancestate: has PR

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions