Running this benchmark with angular 2 is really slow, what am I doing wrong?

[Chang Wang]

Compared to the other frameworks (fiddle: http://jsfiddle.net/kufs0z79/), Angular 2 seems really slow.  

What am I doing wrong?

code here:

http://plnkr.co/edit/yfxVnDaZ2Ki9pjDcFjNC?p=preview

[Sander Elias]

Hi Chang,

I did not dig in very deeply, but when glancing over your code I saw an tremendous lot of $(ele).doStuff(). This will slow things down, and is usually totally not needed in an agnular app. in your component you have direct access to the dom element. Let angular take care of the DOM stuff, and probably you test will speed up quite a bit.

Regards
Sander

​

[CheapSteak]

Hi Sander,

The $(el)s are only in the fiddle for setting up the test environment and grabbing templates for other frameworks

The plunker doesn't have that, just using angular2, setting properties that are bound to views.

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/o9QT5PhzJbo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Eric Martinez]

Chang,

I've been playing with this in it seems that window.requestAnimationFrame is causing change detections. I base this assumption in this comment https://github.com/angular/angular/pull/3876#issuecomment-135894296, also I did a little test to see if I'm right or not

I added the following code

  afterViewChecked() {
    console.log('I\'m being checked!');
  }


  tick () {
      var c = ++this.count;
      this.top = Math.sin(c / 10) * 10;
      this.left = Math.cos(c / 10) * 10;
      this.color = c % 255;
      this.content = c % 100;
      window.requestAnimationFrame(() => this.tick());
  }

afterViewChecked is called everytime the view is being checked, and if you see the console the log grows, and grows, and grows, and grows... I know that a solution could be running it outside angular using zone.runOutsideAngular(() => ...), I tried it and I failed. 

I know this is not a solution, but I hope it gives you at least a clue of how to solve it.

PS : Here's a plnkr with my little test http://plnkr.co/edit/bhy6apYuPHAW5WoEFxey

Regards.

[Sander Elias]

Hi Chang,

Ok, I took a second look, and optimized your benchmark a tad:

http://plnkr.co/edit/I0nCUWeq6IWVDKFSsIy0?p=preview

Problem was, that with the existing code, every single box was updating the screen on its own. My update makes it so, that the screen only updates once after all boxes are updated. If I really dig in, I might even get out some more performance.

Does this clarify your issue enough?

Regards

Sander

[CheapSteak]

Thanks Eric,

I actually initially had the loop running outside, but because the view uses data-binding in its styles, having it outside meant that the values changed but the view wouldn't update unless I ran the assignment operations wrapped inside a `zone.run`

[CheapSteak]

Ah thanks so much Sander, that makes a lot of sense!

I initially thought it was a problem with change detection, surprised but happy that it's something as simple as batching DOM operations :D

[Sander Elias]

Hi Chang,

I'm glad I could help. Curious tough, how does it hold up to other frameworks now?

Regards

Sander

[CheapSteak]

It holds up very well, significantly faster than React

Here's the updated fiddle:

http://jsfiddle.net/kqyz1cku/

and the angular specific code here:

https://gist.github.com/cheapsteak/ef4fea6105469ea34a4e

I had to add in a zone.run due to the benchmark running the loop outside of the Angular component, wonder if that slows things down at all

[Sander Elias]

It looks that it is a tad slower then the version I put out, but judging speed on visual clues is usually not a solid indicator :-D

The zone.run will add some cpu-cycles indeed, but I suspect most of it is in the way the benchmark does the looping. However that's ok, as long as the same thing is used for all frameworks.

I'm not sure why you need toe zone.run actually. I think it's a better solution to bind the function that is actually doing the looping to the zone using zone.bind. Suspect that that will kick up the performance another notch..

Regards

Sander

[Chang Wang]

I'm not familiar with zone.bind, could you give an example of how to use it? The docs are rather sparse at the moment

[Sander Elias]

Ok,

let someOutsideFuctionICanReferTo = () => console.log('hi');

somewhere inside the ng2 component

zone.bind(someOutsideFuctionICanReferTo)

This will make sure that the function is taken into account for change detection, so you can drop the zone.run from your tick function.

Regards

Sander

[Chang Wang]

I think I may be doing something wrong:

    this.zone = new NgZone({enableLongStackTrace: false});
    this.zone.bind(window.benchmarkLoop);

This results in an error of "this.zone.bind is not a function"

If I just do 

NgZone.bind(window.benchmarkLoop)

then the view doesn't update anymore

Or maybe is zone.bind not in alpha.44?

[Sander Elias]

Hmm, Alphas....

Don't sweat it, go with the zone.run for now. I lack the time to invest in this issue right now. Been away for a week(AngualrConnect) didn't help shorten my task-list :)

Regards

Sander

[CheapSteak]

Thanks so much for your help!