Thank you for your reply and example!

Coming from an AngularJS background binding 200 elements to functions would 
have been crippling for performance. An application would then require 
pre-resolving or one-time binding. I haven't been able to read up a lot on 
the changes made for Angular and did not realize the improvements made. 
Looking at it these changes would greatly simplify my code. Thanks for the 
clarification!

Best regards,
Raven

On Monday, January 16, 2017 at 7:36:23 AM UTC+1, Sander Elias wrote:
>
> Hi Raven,
>
> Technically, you are right, and the second solution is a tad faster. I 
> highly doubt you can even measure the difference, though. At least not with 
> at least as a few 1000's of calls on it. Let me explain a little bit, 
> change detection has changed a lot from AngularJS to Angular. While in the 
> past, there was a digest cycle, and functions like tat would have been 
> called up many times, that is not the case anymore.
>
> In Angular, there is no cycle, everything is evaluated just 1 time. So if 
> you have ~200 elements, this just adds 200 function calls. That will not 
> take that much time, a simple function call usually stays under 1 
> nanosecond.
> Take this code, and paste it in your console!
> (function (){
>     "use strict";
>
>     class test {
>         constructor() {
>             this.canSave = true;
>             this.isUnchanged = false;
>             this.isSpecial = () => new Date(); // note I return something 
> that will change on every iteration!
>             // I do this so the benchmark won't be optimized by the 
> compiler to a noop.            
>         }
>         setClasses() {
>           let classes =  {
>             saveable: this.canSave,      // true
>             modified: !this.isUnchanged, // false
>             special: this.isSpecial,     // true
>           };
>           return classes;
>         }
>     }
>
>     let myvar = new test();
>     let someArray = [];
>     let t0 = performance.now()
>     let iterations = 200000;
>     for (let x=0; x<iterations; x++) {
>        let result = myvar.setClasses().special()
>        if (result < Math.random()*t0) {
>            //again doing something to prevent this from being optimized 
> to a NOOP
>            someArray.push(result)
>        }
>     }
>     let t1 = performance.now()
>     console.log(`Each Call to setClasses took ${ 
> Math.ceil(((t1-t0)*10000)/iterations)/10} NANOseconds. `);
> }());
>
>
> On my system, this results into ~1.5 Nanosecond. (and this is doing quite 
> some more work, in this case solely to prevent the JS optimizer from making 
> the loop a no-op. (yes the JS compiler is smart enough to not loop x times 
> if you are just repeating yourself)
> if I change the isSpecial to something that returns a 'static' value, it 
> goes well below 0.2 Nano (note that I'm rounding UP)
>
> Moral of the story, don't do premature optimizations. It probably won't do 
> you any good. In Angular, you don't need to worry as much about this as in 
> angularjs 1.x.
> Also, measuring beats assumptions.
>
> With kind regards
> Sander
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Angular" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

Reply via email to