Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have heard that instanceof operator in java is a performance issue,
Is it true for Javascript too (IE6,IE7,IE8,FF,Chrome,safari,etc.)?
any links to authentic papers would be helpful.
In short: it seems to be browser dependent.
More detailed:
I have found this JSPerf test: http://jsperf.com/instanceof-performance/2 comparing a JavaScript instanceof check versus a boolean check for an existing/missing property in an object.
The overall result (beware of the small number of samples) is that in Chrome both methods are alike with benefits for instanceof. In FF, however, the property check is faster than the instanceof operator. Update Apr 2017: As #ngryman pointed out: In both, recent FF and Chrome versions, doing property checks seems significantly faster than instenaceof.
Would be interesting to extend that test with a case like checking if a string comparison like obj.type == 'MyClass' has a strong influence on the subject.
That's not true for Java anymore -- see here.
As for Javascript, I couldn't find any articles that discuss this, but I highly doubt that instanceof would be cause any performance issues. If you need to use it, I would say go for it, and then reconsider only if you're running into performance problems.
You could pretty easily make your own JavaScript benchmark similar to this one linked from Kaleb's link.
I wouldn't worry about performance of the instanceof operator myself, because JavaScript itself is rarely a reason of performance problems. DOM manipulations usually take much more time. However, if you need instanceof in a heavy used loop, I would suggest to profile it using FireBug profiler.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have an enterprise javascript web application where I utilize the for-in loop a lot. When I profiled the application at a potential bottleneck, Chrome profiler gave me lots of exclamation mark icons next to function names, and alerted that those functions were not optimized due to ForIn loop.
The profiled code had many functions using for-in loop, also in recursion.
I couldn't find any related material on the internet about this. Why these loops affect performance? How to work it around? Can it really be a bottleneck?
You can learn more about optimization of For-In loops, at the following link
Optimization killers in Node.js
It is the same case for google chrome javascript, Node.js and Chrome implements V8 Javascript engine
If you are using loop like
for(var prop in myobj){
}
The reason chrome assumes it becuase, the for in loop will loop all the methods internal native properties and some of the property which is in accessible similar we see in the google chrome console
that could be the reason
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
which one is faster
document.getElementsByName('tempName')[0].value
or
$('[name="tempName"]')[0].value
I want to know because I'm writing js codes were I have to use it for around 10 thousand times on every change of a single field and I want to know its effect on performance.
The first one seems to be faster. Using pure javascript.
Tested with jsperf: http://jsperf.com/performance-fsdfsd
Pure JavaScript should work faster here. So this one is
document.getElementsByName('tempName')[0].value
The first one. No doubt about it. Not a single test needed for that.
However, the questions you should be asking yourself is:
By how much?
Does it really matter?
How big is your app that you worry about these things?
Is it worth sacrificing readability & cross-browser support for such a tiny gain?
If you can make do without jQuery as a dependency, then you can save yourself & your users some precious bytes. But, if you anyhow need jQuery elsewhere on the page, I don't think fiddling like this is gonna make a real-life difference.
Bottom line: you should test your real-world example, not just this one abstract line. The vanilla JavaScript might be faster, but if it makes no difference to your app, then why bother?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Javascript : What are the different conditions when javascript work in IE but not in Firefox or some other browser?
one that i know of is that while using certain window events..
What other scenarios can cause javascript to not work properly?
The answer is too complex to fully list here. Use sites like http://caniuse.com that will tell you which JavaScript is available in which browser.
Generally speaking, all browsers implement JavaScript differently. Microsoft have long been stuck in their own world, implementing their own ways to do things, whereas everyone else seems to try and conform to the standards as much as possible. Microsoft are coming around to the "standards" way of doing things, and from what I hear, IE11 will be a massive step in this direction.
As already mentioned, you can use http://caniuse.com/ to find what you can and can't do in different browsers, but then you'll likely end up doing what many others have done...write your own API which works around these to achieve a task...which is a bit unnecessary, unless you can find a ground-breaking way to implement your API that will be beneficial to other developers.
APIs like jQuery already work around these differences. The aim with these libraries is to provide clean JavaScript, whilst being completely transparent from the underlying JavaScript implementation.
Also, look into "shim"/"polyfill" implementations. These are used when a core feature that is recognised as part of an ECMAScript version has not been implemented in the browser. These provide the implementation for you, if it is not natively supported.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is better to use in javascript to square some value.
Math.pow
Math.pow((circle2.x - circle1.x), 2)
Or my own function
square(circle2.x - circle1.x);
function square(a){
return a*a;
}
It is nearly always better to use a library then write your own code, unless you have a good reason not to. Reasons why:
It saves you work.
It is well-tested code, while your code might introduce bugs.
Someone else who looks at your code will know what Math.pow is, so it makes your code easier to read.
Obviously this is a very simple case, in which your own function is unlikely to cause a problem. Still, it is better to get in the habit of using libraries whenever possible.
By the way, Math.pow performs a lot of handling of special cases. This illustrates that even a simple function can have more pitfalls than it appears at first. By using a library, you don't have to worry about handling all of the edge cases yourself.
You should always prefer to use library functions - what is the point in reinventing the wheel?
Library functions are optimized and may cater for some corner cases you are not aware of...
Are you going to provide own implementation of multiplication as well?
For a power 2 specifically I would use multiplication because you really don't lose any legibility. Even more if speed is important, multiplying will probably be faster than function calls.
edit: I mean don't even create a function... just a*a.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm preparing a presentation about JavaScript in different browsers.
I know that there are several issues with Mozilla. For example the constructor of the Date object will not accept the ISO date string. It will result in invalid date.
I've been looking for a errata which lists all known issues of this browser in one place. But I couldn't find such.
Q: Does anyone know some link or document that lists the issues of this browser. At least the most significant ones?
Thanks in advance.
What you seem to want is bug 445494 - a tracking bug for all known ECMAScript 5 compliance issues. Look at the open bugs that it depends on. There are apparently two strict mode issues left (disabling document.all in strict mode and throwing an exception if a variable is accessed too early), String.match and String.replace methods don't update RegExp.lastIndex property, some non-standard special treatment for the Array.length property and a few similarly small issues.