I'm into selectors performance lately, and it's bugging me that the browsers which currently implements the Selectors API don't use document.getElementById when a simple #id is being passed.
The performance penalty is huge, so library authors continue to implement their own way around that.
Any ideas?
After making my comment above, I decided to follow through:
From Node.cpp in the Chromium source
if (strictParsing && inDocument() && querySelectorList.hasOneSelector() && querySelectorList.first()->m_match == CSSSelector::Id) {
Element* element = document()->getElementById(querySelectorList.first()->m_value);
if (element && (isDocumentNode() || element->isDescendantOf(this)) && selectorChecker.checkSelector(querySelectorList.first(), element))
return element;
return 0;
}
So it does map on getElementById, it is just that parsing the string looking for selectors is an expensive operation.
Tbh. the performance penalty is insignificant... I really doubt you're going to do 100.000 id lookups per second, if you do, then QSA performance is actually the last thing you should look at.
As to why, adding an extra if/else might make id lookups more performant, but then other css selectors will be a fraction (still insignificant) slower. Why optimize QSA to deal with id lookups when there's a specialist method to do exactly that a lot faster anyways.
In any case, browsers are aiming for speed and leaving out stuff like this makes the overall performance charts look a lot better. In this benchmark race it's REALLY about every single millisecond, but for the developers... please be realistic, other benchmarks are more important, QSA performance shouldn't really be a factor anymore.
As for developer convenience, it works, it's still so fast you won't notice it in actual applications (I challenge you to show me where it's IS VISUALLY noticable whilst still being a sane program ;o).
Maybe because if they did that, they would have to add a check to see if its a simple id query (no modifiers) which would slow down every other query? It might not be a huge performance hit to do the test, but its difficult to speak for other developers.
I think if you are worried about it you can add a func like getObByID that checks for document,getElementById, uses it if it exists, else uses the selector. Maybe the developers don't feel the need to add this type of abstraction when you can easily do it yourself, and it would be up to developers to remember to use it, and increase learning curve.
I was comparing getElementById() and querySelector() and found that someone has already done performance comparisons and calculations.
It certainly looks as though querySelector() wins every time... and by a considerable amount.
Related
Let's say you have a typescript object, where any element can be undefined. If you want to access a heavily nested component, you have to do a lot of comparisons against undefined.
I wanted to compare two ways of doing this in terms of performance: regular if-else comparisons and the lodash function get.
I have found this beautiful tool called jsben were you can benchmark different pieces of js code. However, I fail to interpret the results correctly.
In this test, lodash get seems to be slightly faster. However, if I define my variable in the Setup block (as opposed to the Boilerplate code), the if-else code is faster by a wide margin.
What is the proper way of benchmarking all this?
How should I interpret the results?
Is get so much slower that you can make argument in favour of if-else clauses, in spite of the very poor readability?
I think you're asking the wrong question.
First of all, if you're going to do performance micro-optimization (as opposed to, say, algorithmic optimization), you should really know whether the code in question is a bottleneck in your system. Fix the worst bottlenecks until your performance is fine, then stop worrying overmuch about it. I'd be quite surprised if variation between these ever amounted to more than a rounding error in a serious application. But I've been surprised before; hence the need to test.
Then, when it comes to the actual optimization, the two implementations are only slightly different in speed, in either configuration. But if you want to test the deep access to your object, it looks as though the second one is the correct way to think about it. It doesn't seem as though it should make much difference in relative speeds, but the first one puts the initialization code where it will be "executed before every block and is part of the benchmark." The second one puts it where "it will be run before every test, and is not part of the benchmark." Since you want to compare data access and not data initialization, this seems more appropriate.
Given this, there seems to be a very slight performance advantage to the families && families.Trump && families.Trump.members && ... technique. (Note: no ifs or elses in sight here!)
But is it worth it? I would say not. The code is much, much uglier. I would not add a library such as lodash (or my favorite, Ramda) just to use a function as simple as this, but if I was already using lodash I wouldn't hesitate to use the simpler code here. And I might import one from lodash or Ramda, or simply write my own otherwise, as it's fairly simple code.
That native code is going to be faster than more generic library code shouldn't be a surprise. It doesn't always happen, as sometimes libraries get to take shortcuts that the native engine cannot, but it's likely the norm. The reason to use these libraries rarely has to do with performance, but with writing more expressive code. Here the lodash version wins, hands-down.
What is the proper way of benchmarking all this?
Only benchmark the actual code you are comparing, move as much as possible outside of the tested block. Run every of the two pieces a few (hundred) thousand times, to average out the influence of other parts.
How should I interpret the results?
1) check if they are valid:
Do the results fit your expectation?
If not, could there be a cause for that?
Does the testcase replicate your actual usecase?
2) check if the result is relevant:
How does the time it takes compare to the actual time in your usecase? If your code takes 200ms to load, and both tests run in under ~1ms, your result doesnt matter. If you however try to optimize code that runs 60 times per second, 1ms is already a lot.
3) check if the result is worth the work
Often you have to do a lot of refactoring, or you have to type a lot, does the performance gain outweight the time you invest?
Is get so much slower that you can make argument in favour of if-else clauses, in spite of the very poor readability?
I'd say no. use _.get (unless you are planning to run that a few hundred times per second).
Usually when I have to parse number in javascript I use code like
var x="99"
var xnumber= x-0
instead of
var xnumber= parseInt(x)
Is there any problem in using this Code ( in the performance or the structure ) and I want to know if there is any problem
Using the "x - 0" method is going to be significantly faster in most browsers.
Here's a JSPerf that shows the performance difference.
You can do you own A/B performance testing using JSPerf.com
However, you may still want to use parseInt() in some cases, because it's a little clearer. Although, truthfully, any experienced javascript developer isn't going to have any trouble understanding the faster way.
If the line of code is only going to run once every half second or so (or whenever the user types a letter), you can use parseInt without worrying.
However, if this bit of code is in a loop that runs a few thousand times or more, you should definitely use x - 0.
Both ways should work but it is in my opinion "cleaner" to parse any String with the function which is made for this and not with this little trick.
You are also less likely to run into conversion issues and should you write code in other languages you are in general better of with the way the developer intended to use. Many other languages will not allow your first way of "casting"
performance wise you wont see much of a difference, but it's not very readable. I tend to believe parseInt("4", 10) is the right solution because it's inline with how you parse other values in javascript (i.e. parseFloat("4.0")) so you're keeping more consistent by sticking with one method of parsing numbers.
I don't believe it will perform better or worse. Performance optimisations like that one are generally negligible, and can be inconsistent across various platforms. However, the former method using parseInt gives a much better idea of your intentions to other programmers. Unless you have a very good reason to optimize this statement, and you are sure it really runs faster in your target environment, you are recommended to stick to the more readable version (this case, parseInt).
Update: I recommend reading this thread about micro-optimisations: https://softwareengineering.stackexchange.com/questions/99445/is-micro-optimisation-important-when-coding/
According to tests with jsperf a for loop in javascript with this form:
for (var i = 0, item; item = itemsArray[i++];){
item = Math.random();
}
is several orders of magnitude faster than a typical for loop, even in older browsers like IE8. I have not been able to find another reference to this loop construct and am wondering why is it so much faster?
Also, I've looked through the sources of some javascript libraries, like jQuery and Knockoutjs and they do not use this construct in their code.
Which leads me to be suspicious. If this form of looping is so much faster, why don't popular libraries, written by people much smarter, use it?
Am I missing something where this loop is not as good as it looks on the surface?
Am I missing something where this loop is not as good as it looks on the surface?
Everytime a single item from your itemsArray is falsy, your condition fails to do what is expected.
Actually that's also the reason why your test says it would be much faster, that's just because it doesn't even do the first iteration as itemsArray[0] = 0. An updated jsperf which iterates [1..1001] shows that the for loops perform quite similar, yours actually being one of the little slower ones.
why don't popular libraries, written by people much smarter, use it?
They focus on good algorithms, readability, usability, cross-browser-support (and of course correctness), not about micro-optimisation.
There are less operations i guess, using .length in loop is slow, it does not check for stuff like i < len either. It does only verify item return true to go on looping (which may cause severe issue if any of your item exist but return false)
I guess library don't use this cause it's inelegant, less readable, and may cause the issue mentioned above ? It's not a bullet-proof loop.
while (div.hasChildNodes()) {
fragment.appendChild(div.firstChild)
}
while (div.firstChild) {
fragment.appendChild(div.firstChild)
}
Comparing the two pieces of pseudo code above, they both append each child of div to fragment until there are no more children.
When would you favour hasChildNodes or firstChild they seem identical.
If the APIs are so similar then why do they both exist. Why does hasChildNodes() exist when I can just coerce firstChild from null to false
a) micro-optimization!
b) Although it seems to be common practice, I'm not fond of relying on null/non-null values being used as a substitute for false/true. It's a space saver that's unnecessary with server compression enabled (and can sometimes call subtle bugs). Opt for clarity every time, unless it's demonstrated to be causing bottlenecks.
I'd go for the first option, because it explains your intent perfectly.
There's no functional difference between your two implementations. Both generate the same results in all circumstances.
If you wanted to pursue whether there was a performance difference between the two, you would have to run performance tests on the desired target browsers to see if there was a meaningful difference.
Here's a performance test of the two. It appears to be browser-specific for which one is faster. hasChildNodes() is significantly faster in Chrome, but firstChild is a little bit faster in IE9 and Firefox.
I would suggest hasChildNodes() over firstChild just due to the return; hasChildNodes() returns false if it's blank, while firstChild returns null; which allows you to parse the data more efficiently when it comes to checking if they exist. Really, it depends on how you plan on manipulating the DOM to achieve your results.
Your two examples will usually* behave identically, aside from some (probably) negligible differences in speed.
The only reason to favor one over the other would be clarity, specifically how well each construct represents the ideas the rest of your code is implementing, modulated by whether one of them is easier for you to visually parse when you're reading the code. I suggest favoring clarity over performance or unnecessarily pedantic correctness whenever possible.
* Note: I'm assuming you're running this code on a webpage in a vaguely modern browser. If your code needs to run in other contexts, there might be a significant speed difference or even functional (side-effect) differences between .hasChildNodes() and .firstChild: One requires a function call to be set up and executed, the other requires that a script-ready DOM compliant representation of the first child be constructed if it isn't already available.
Assuming DOM calls are slow, you could optimize further (at the expense of readability) by using a single call to firstChild:
var child;
while ( (child = div.firstChild) ) {
fragment.appendChild(child);
}
... although (bizarrely, to me) this apparently doesn't help at all and makes things worse, according to this jsPerf: http://jsperf.com/haschildnodes-vs-firstchild/2
As to why both methods exist, remember that DOM is not exclusive to JavaScript. In a Java DOM implementation, for example, you would have to explicitly compare firstChild (or more likely firstChild()) to null.
I am doing work involving a lot of DOM manipulation. I wrote a function to more efficiently change common styles on objects using "hotkeys". It simply interprets this:
styles = parseStyles({p:"absolute",l:"100px",t:"20px",bg:"#CC0000"});
as this:
styles = {position:"absolute",left:"100px",top:"20px",background:"#CC0000"};
This came about mainly to save me from having to read so much, and because I wanted to see if I could do it :) (as well as file sizes). I find these hotkeys easier to look at; I am setting and resetting styles dozens of times for different custom DOM objects.
But, is having a bottleneck like this going to be a significant burden on performance and runtime if my page is using it up to 5,000 times in a session, about 10-25 executions at a time?
function parseStyles(toParse){
var stylesKey =
{h:"height",p:"position",l:"left",t:"top",r:"right",b:"bottom",bg:"background"},
parsedStyles = {};
for (entry in toParse){
if (entry in stylesKey){
parsedStyles[stylesKey[entry]] = toParse[entry];
} else {
parsedStyles[entry] = toParse[entry];
}
}
return parsedStyles;
}
I find that setting non-computed styles is rarely ever needed any more. If you know the styles ahead of time, define a class for that in your CSS and addClass or removeClass from the necessary objects. Your code is a lot more maintainable and all style-specific info is in your CSS files rather than your Javascript files. Pretty much, the only time I set formatting-style info directly on an object anymore is when I'm using computed positions with absolute positioning and even then, if I rack my brain hard enough, the positioning problem can usually be solved with plain CSS/HTML.
The examples you cite in your question look like static styles which could all be done with a CSS rule and simply doing addClass to an object. Besides being cleaner, it should be a lot faster to execute too.
It looks like what you're doing is using run-time parsing in order to save development-time typing. That's fine if you don't notice the performance difference. Only you can know that for sure because only you can test your app in the environments that you need it to run (old browser, old CPU, stress usage). We can't answer that for you. It would certainly be faster not to be doing run-time conversion for something that is known at development time. Whether that speed difference is relevant depends upon a lot of details and app requirements you haven't disclosed (and may not have even seriously thought about) and could only be figured out with configuration testing.
If it were me and I had any thoughts that maybe I was calling this so much that it might impact performance, I'd find it a lot less work to do a little extra typing (or search and replace) and not have to test the potential performance issues.
Memoize your parsing function.
The simple fact is, that over some finite area of time, the number of actual styles, or full style strings that you will process will likely be quite small, and will also, likely, have a reasonable amount of duplication.
So, when you go to parse a style expression, you can do something simple like store the expression in a map, and check if you've seen it before. If you have, return the result that you got before.
This will save you quite a bit of time when reuse is involved, and likely not cost you much time when it's not.