Ryan Campbell investigates the cost of enumerable loops in Prototype. The resulting numbers are pretty dramatic when dealing with larger arrays. One thing to keep in mind though is that for only a few iterations over arrays with a small number of elements then the penalty is probably small enough that it won’t cause problems.
Benchmarks using the various JavaScript libraries is something that I’d expect to see more of. Soon or later someone will post benchmarks between Prototype, YUI and JQuery on various tests. The benefit from having numbers like this is that eventually all libraries will adopt the fastest approach that meets their goals.
One reply on “Too Much Of A Good Thing, JavaScripts Loops In Prototype”
yeah a friend of mine was using jQuery for a large Purchase Order application. It was huge. Huge arrays. Lots of stuff moving about client side. Seconds to sort, et al. He then decided to rip out jQuery and suddenly everything (after a few days of ripping out) became faster.
I think libraries, js libraries in this instance, can be very helpful, but hurtful when the developer using them doesn’t understand that abstraction can potentially hinder them in the long run. In server side land, ActiveRecord is great, but really, straight SQL is mighty fast, and you just have to know when its appropriate. There are trade offs for development ease vs speed, and i think you can continue to use libraries as long as they make it easy to get back to basics when need be.
Its also important to realize the scope of the code you are going to be using. In my personal development I might let slide somethings that are easier for me to develop (like adodb for php let say), even though I know that using mysql_* commands are alot faster. But for its intended purpose its gonna be ok.
At what point do you abstract? I think that in this current hype of web 2.0, where many applications are created out of abstractions of APIs and other code bases lots of people are not taking into consideration performance. It hurts new developers who rely on it, thinking naively that since so and so uses it it must be fast. Rails has a find_by_sql method for a reason.