I am going to improve the perfomance of my angular app. So I decided to use {{::variable}} more often (>angular 1.3). For translations I used the writting {{'key.header'|translate}}.
Is a performance improvement possible if i use {{:'key.header'|translate}} or does angular know that these strings won't change?
Thank you
The only way to indicate to angular that your string would not change is using {{::variable}}. And yes, it's a performance improvement because you are telling to angular to evaluate that expression once and then ignore it (avoiding two-way binding) and never watch it again. So,
less watchers = better performance
NOTE:
You can set an angular expression using ::, only if your expression wouldn't be changed over the time. In your case(about your comment), if you want to use that expression to get a translated version on a string, you should not use it then, because the user may changes the language any time and it needs got changed.
Conclusion
You should use :: over angular expressions that wouldn't be changed over the time. :: is a way to declare a constant and reduce your watchers, getting a better performance.
Related
It seems like angularjs 1.x filter is not recommended, with the reason given below:
http://blog.scalyr.com/2013/10/angularjs-1200ms-to-35ms/
Angular runs every single filter twice per $digest cycle once something has changed. This is some pretty heavy lifting. The first run is from the $$watchers detecting any changes, the second run is to see if there are further changes that need updated values.
I wonder if it make sense to either:
Use bind-once with filter
Write custom directive that ensures no additional watch is required?
I'm currently working on the performance of an angularJS application, and was wondering if there is any difference in performance between these two examples:
http://plnkr.co/edit/T5aHybkkCoF5MDzXX2Kk?p=preview
http://plnkr.co/edit/sX2ffPPOQTyFbb70elwp?p=preview
The difference is that in the first example, in the file 'testdirective.html' the ng-if boolean is not bound in a one time expression. However, it is already bound as a one-time binding in the 'index.html'.
<div ng-if="enabled">
vs
<div ng-if="::enabled">
Is using a one-time expression in the directive as well as in the index file better for the performance?
Thanks!
Yes, there will be a performance difference (although negligible in this case).
The directive doesn't take into account if the value passed to it was one-time bound or not, so if the directive's template doesn't use a one-time binding it will register a new watcher.
The cost of running this watcher during the digest cycle will bascially be the difference in performance in the two examples.
An extra note on your example that doesn't really touch the question is that the following two cases will behave the same:
<testdirective enabled="::true"></testdirective>
And
<testdirective enabled="true"></testdirective>
In the second case true will be treated as a constant that cannot change and the registered watcher will be removed, just like with a one-time binding.
Which of these two is better?
<span translate="key">Key</span>
or
<span>{{'key' | translate}}</span>
They are both good and work fine but in first case I must fill the content of the element.
Using the attribute is better performance-wise, especially if you intend to use translations on elements that will be inside ngRepeats. This is because the way filter work internally.
Every time there is a digest cycle, angularjs reloads all the expressions containing filters. This is because angular can't possibly know if a filter has changed or not. What this means is that, even if the key of the translation has not changed, but some other value on the scope has, angular will look through every translation and translate it again, just to come to the conclusion that they all remain the same.
Attributes are smarter, because the developer of the directive has explicit control over when it should re-render and what watcher should be created.
Edit: And as far as I know, there is no need to fill the content in the first use-case. You can just leave it empty.
From this question and this answer, it seems that using expressions will cause the value to be evaluated from scratch every time. But I've searched the documentation and tutorials, and I haven't found a reference for this statement.
In my mind, both are wrapped in a $watch() and so when the $digest() cycle runs it will see whether the value inside ng-bind or {{}} has changed.
On performance, why is ng-bind better than {{}} as has been suggested, and where's the reference?
Details like this aren't always available in the documentation - you have to read the source. I took a peek and it seems that (as of 2014-11-24) they both work in a very similar way. Both cause a single directive to be instantiated to change the value when needed (the curly interpolation directive is generated on the fly).
Both directives evaluate the expressions involved on every $digest just like everything else. The main difference is that while ng-bind doesn't do any further processing on the value, with curlies, the entire interpolated text is recalculated on every digest. Essentially a string is built using $interpolate and that is compared with the previous value (this happens within the bowels of $digest). Neither way will update the DOM if the value (either the plain value with ng-bind or the interpolated result with curlies) hasn't changed.
To me the accepted answer on that question is a more compelling reason to use ng-bind, i.e. you can use it to prevent a visible flash of the template tags before Angular loads and compiles them, without resorting to hacks like ng-cloak.
Depending on variables there may also be cases where curly interpolation is actually more performant. One situation I can think of is when using ng-bind instead of interpolation requires you to create a lot of otherwise redundant <span> elements, and that tips the scales in the other direction. An interpolation expression also causes a single watcher to be created for the entire string independent of how many variables you use, as opposed to ng-bind which creates one watcher for each instance.
But as always, don't optimize for performance early, and if you do, profile to find out which part really matters.
The major difference between ng-bind and {{}} is that ng-bind creates a watcher for variable passed to it(i.e. name as in above example), while curly brackets({{}}) will (store the entire expression in memory i.e. }perform dirty-checking and refreshing the expression in every digest cycle even if it is not required.
ng-bind will only apply when the value passed is changing actually.
for more details refer below link:
http://www.ufthelp.com/2015/11/difference-between-and-ng-bind-in.html
I have a question concerning the performance, reliability, and best practice method of using Extjs's update() method, versus directly updating the innerHTML of the dom of an Ext element.
Consider the two statements:
Ext.fly('element-id').dom.innerHTML = 'Welcome, Dude!';
and
Ext.fly('element.id').update('Welcome, Dude!', false);
I don't need to eval() any script, and I'm certain that update() takes into consideration any browser quirks.
Also, does anyone know if using:
Ext.fly('element-id').dom.innerHTML
is the same as
d.getElementById('element-id').innerHTML
?
Browser and platform compatibility are important, and if the two are fundamentally the same, then ditching Ext.element.dom.innerHTML altogether for update() would probably be my best solution.
Thanks in advance for your help,
Brian
If you do not need to load scripts dynamically into your updated html or process a callback after the update, then the two methods you've outlined are equivalent. The bulk of the code in update() adds the script loading and callback capabilities. Internally, it simply sets the innerHTML to do the content replacement.
Ext.fly().dom returns a plain DOM node, so yes, it is equivalent to the result of getElementById() in terms of the node it points to. The only subtlety to understand is the difference between Ext.fly() and Ext.get(). Ext.fly() returns a shared instance of the node wrapper object (a flyweight). As such, that instance might later point to a different node behind the scenes if any other code calls Ext.fly(), including internal Ext code. As such, the result of a call to Ext.fly() should only be used for atomic operations and not reused as a long-lived object. Ext.get().dom on the other hand returns a new, unique object instance, and in that sense, would be more like getElementById().
I think you answered your own question: "Browser and platform compatibility are important, and if the two are fundamentally the same, then ditching Ext.element.dom.innerHTML altogether for update() would probably be my best solution." JS libraries are intended (in part) to abstract browser differences; update is an example.
#bmoeskau wrote above, update() provides additional functionality that you don't need right for your current problem. Nevertheless, update is a good choice.