Balazs, like I said, I already know it is a premature optimization. But, I still want to know what the reason would be why these discrepancies exist. And to your comment about if I have to perform a loop, then I'm not doing it right - you don't know what the JS is being used for, nor do I, I am thinking in a theoretical sense if somebody was using a web worker to process large data sets, perhaps some sort of image manipulation, and in that sense, this is a perfectly legitamate question. In this scenario, perhaps I'm not creating many millions of objects per second, but I have a couple of objects created that have to call some sort of superclass function once per operation. Either way, the .call, .apply, etc would still be used many millions of times. So thanks for the answer, and before flaming the next person, consider that there are legitimate uses that you haven't thought of.
Shane On Tue, Dec 21, 2010 at 4:37 PM, Balázs Galambosi <[email protected]>wrote: > Shane Tomlinson wrote: > > I realize it is probably a micro-optimization and I don't > > need to change my code in most places, but I was thinking > > if I ever came into a performance critical loop where a > > superclass' function was called, this could start to become an issue. > > I tend to dislike when people are dropping the "premature > optimization" line everywhere, but until you don't see any performance > issue with your codebase you should leave it as is (considering that > it is well engineered and highly maintainable). > > Let's see, we're talking about 3 000 000 op/sec difference. It's less > then 1 us (0.0000001s) which is basically nothing. If you need to > create that many object in a loop, you're doing it wrong. > > As to why it happens, I think modern browsers try to optimize things > that are used frequently, and this is why `apply` may become highly > efficent in the latest versions of Chrome. > > > - Balázs > > > 2010/12/21 Shane Tomlinson <[email protected]>: > > Hi guys, perhaps somebody can shed some light on this, especially in > regards > > to the recent postings about performance issues regarding the mutability > of > > the prototype chain and arguments. A pattern that I rely on quite > heavily > > is to create one class that is a subclass of another. I use a pretty > > standard extend function that sets up the prototype chain to create a > > class hierarchy. I was reading all of the posts involving the > performance > > penalties of using "arguments" and thought to myself, "I use arguments > all > > over the place, every time I call a super class's overridden function." > I > > set up a performance test in jsperf > > (http://jsperf.com/call-vs-apply-with-arguments) and was a bit surprised > at > > the results of using call vs apply with an empty array vs apply with > > arguments. > > But basically, from all the talk of using arguments having a performance > > penalty, I was expecting that functionReference.apply( this, arguments ) > > would be very slow and functionReference.call( this ) to be the fastest - > > and this indeed is generally the case. But Chrome 10 and Opera 11 are > > standouts. In Chrome 10, functionReference.apply( this, arguments ) is > > several million ops per second faster than functionReference.call( this > ). > > In Opera 11, functionReference.apply( this, [] ) is the fastest by a > long > > shot and functionReference.apply( this, arguments ) is the slowest, about > 6 > > million ops/second slower than when using an empty array for the > arguments. > > Can anybody shed some light on this as to why? I realize it is probably > a > > micro-optimization and I don't need to change my code in most places, but > I > > was thinking if I ever came into a performance critical loop where a > > superclass' function was called, this could start to become an issue. > > http://jsperf.com/call-vs-apply-with-arguments > > Thanks, > > Shane > > > > -- > > --------------------------------------------------- > > http://www.shanetomlinson.com > > http://www.aframejs.com - a Javascript MVC library making traditional > app > > development in the browser much easier > > > > -- > > To view archived discussions from the original JSMentors Mailman list: > > http://www.mail-archive.com/[email protected]/ > > > > To search via a non-Google archive, visit here: > > http://www.mail-archive.com/[email protected]/ > > > > To unsubscribe from this group, send email to > > [email protected]<jsmentors%[email protected]> > > > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected]<jsmentors%[email protected]> > -- --------------------------------------------------- http://www.shanetomlinson.com http://www.aframejs.com - a Javascript MVC library making traditional app development in the browser much easier -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
