Major performance concerns with pace-js

[charliebravodev]

Issue type

I'm submitting a ... (check one with "x")

• bug report
• feature request
• question about the decisions made in the repository

Issue description

Current behavior:
Its seems that change detection is called way too many times on most pages. With the starter kit, the NbLoginComponent causes method getConfigValue() to be called roughly 350 times in Safari and 230 in Chrome. When the page takes a while to load in Chrome, the counter goes up to 5000+ calls after a few seconds.

When removing pace-js (loading bar at the top), the counter drops down to 20 on both Safari and Chrome, yet acceptable but still a bit high IMO.

Expected behavior:
Considering that getConfigValue() is used twice in the NbLoginComponent template, and also considering that change detection runs twice as more in Angular CLI's dev mode, I would still expect the number of calls to be around 2-6, not ~90 times (350/2/2). I have tried a production build and the number drops (as expected) to roughly half that amount, but still remains too high.

Steps to reproduce:

• Clone the starter kit of this repository.
• Create a login component identical to Nebular's default NbLoginComponent.
• Change the following lines:

getConfigValue(key: string): any {
  return getDeepFromObject(this.config, key, null);
}

to

private count: number = 0;

getConfigValue(key: string): any {
  this.count++;
  console.log(this.count);
  return getDeepFromObject(this.config, key, null);
}

• Start the application and look at the console:
  • Safari 11.1 (12605.1.33.1.3):
    
  • Chrome 65.0.3325.181 (Official Build) (64-bit)
    

And without pace-js:

• Safari:
  
• Chrome:
  

Related code:

Other information:

npm, node, OS, Browser

node v7.1.0
nom v4.6.1

Angular, Nebular

ngx-admin v2.1.0

[nnixaa]

Hey @charliebravodev, thanks for the detailed bug report!

As far as I can tell we should make pace-js work out of ng-zone at least. It also would make sense to use onPush strategy for auth components to decrease change detection triggers amount.

Do you have any other ideas how this could be improved?

[charliebravodev]

@nnixaa very welcome. Thank YOU for making this amazing piece of code available to the world!

I'll agree with you on both suggestions, but was wondering whether a JS powered loader is the best solution. How about a CSS only option ? I think the discussion might lie into which kind of loader is best suited. Developers would probably want to have an option to define the loading bar provider they want.

I like the idea of the loader being at the top of the page, it's discreet, and makes the page alive when nothing happens and also gives users the feeling that it's going to happen soon (note however that I have seen cases where the loader did not stop at all after redirecting from logout, but I couldn't reproduce consistently the issue).

How about a CSS version like this one ?

But in the end, what is the point of having a JS loader if we never set progress manually anyway 😃