Learn to Loop Responsibly
Looks familiar right? I’m also guessing that your collection sometimes isn’t a direct local variable, but is probably part of a larger object like a view model or something similar:
Thus you might consider looping over the set of teachers above like so:
Unfortunately, as your application grows this format may end up biting you in the ass when it comes to performance.
(The “loop comparison” being the highlighted section)
Most developers understand that the x < y part is calculated every time around, but most don’t consider that the calculation of finding the value of x and y themselves is also performed. That means, in the above example, that student.teachers.length is calculated each time we go through the loop. This is not a big deal when your collection is small or the number of hops from the root object to the list property we want is small, but when you start doing lots of iterations it really adds up!
Lets see what happens when the collection gets bigger and the distance from the root object to the list property grows like the spaghetti monstrosity we all seem to end up working on as code ages. I built a simple object like so that contains a list deep in the structure:
Then I filled the “h” array with 100,000,000 random integers (yeah probably not the average array size, but it helps illustrates the point)
Next I ran three loops over the collection with the following variations.
BAD: Loop #1 uses the loop comparison i < data.a.b.c.d.e.f.g.h.length which means we hop down the object chain and then find the length of the array each time.
BETTER: Loop #2 saves the h array to a local variable called hlocal so we don’t have to hop down the object chain, but we still calculate the collection length every time using the loop comparison i < hlocal.length.
BEST: Loop #3 saved the length of the array h to a local variable called len which means we hop down the object chain and calculate the array length exactly one time and end up with the simple loop comparison i < len.
Chrome 39 & Firefox 32 : I was pleased to see that the looping differences had no effect on chrome or Firefox. From what I understand Chrome and Firefox do some optimization to prevent these types of issues so it was not much of a surprise.
IE 11: Here is where things break down. This probably comes as no surprise to most of us, but IE doesn't appear to do any optimizations for you and is incredibly slow even using the fastest loop format compared to Firefox and Chrome.
The last thing I would like to point out is that the above tests were run over a static list of integers. Things can get much much worse with this fairly common pattern…
You’re looking at bringing an application to it’s knees pretty quickly.
Loop Responsibly. ☺