This or that for performance #2

Let’s say you have a humongous image gallery. Like 300 images. And each image has a bunch of data attached to it like image info, etc. Then all of this information is organized and placed in a visibly hidden unordered list.

Due to the nature of the gallery, utilizing elements from the unordered list isn’t really possible, and as a result the list really just serves as data storage for the gallery + some SEO value.

When the page loads and your script runs you have two options:

1. Leave the unordered list alone, and just grab data from it as needed
2. Loop through the entire unordered list and store all of the data in JS Arrays. Then remove the unordered list from the DOM .

So what approach do you think is best?

Did you already tested both the cases with mobile devices? Test it with a low config android phone and iPhone 3 or less and observe these 2 scenarios:

- How fast the initial page render happens
- How fast it renders while navigating.

As you already know the number of elements are fixed (300), the best approach would be direct testing.

Without testing, #1 would be better. Any memory gains from getting rid of the elements in the DOM will be offset somewhat by the data being stored in JavaScript. You’d still end up with memory being used—how much of a difference remains to be seen.

If it’s a wash, I guess it then depends on what’s more important: page load performance or how often you need to access the data. Because it’s certainly a hit creating and populating the arrays, but then access seems to be much better once their built, at least compared to using jQuery:

(that’s my first jsperf so hopefully I did it right )

^ I guess you should test it for around 300 elements (instead of 5000). Performance measurements may not be linear and easy!

Also test environment and real project may not be the same, so results may lead to wrong understanding about browsers and devices. According to method #1, DOM access will happen only when user interacts, which may not cause performance issue even though test cases show the opposite.

Option 2 or loop is “expansive” in performance and Object properties and array items are slower than variables and the deeper you go with array the slower you get .

Yes what’s that 5000? You running a particle system i should know ?

But how often you need to access the data is super imported with js /HTML, it’s also costly on target time performance…but i always say to myself if it’s not that usable in use then ill dump it from the DOM which i think it has what we call in our language one of the worst GC method known to man (GC is just a term you know what i am referring for) DOM operations are always more expensive. in performance .

But really the challenge today is you need to test and understand performance issue over 7-8 platform (referring to browser & mobile) with JavaScript, that is a very hard topic.

This is theoretical, but the theory is based on a few things:

• The DOM will be read regardless of taking #1 or #2.
• The #2 approach potentially has a greater impact on perceived performance because of the enumeration of the elements, storing their data, and removing them from the document.
• The #1 approach has the potential to be slower due to access via the DOM for the same elements.

So I would do a combination of the two. As the data is read from the element, cache it in the array and then remove the element. This has the following advantages:

• The data is loaded on demand and processed only if selected by the user.
• The DOM tree shrinks as users select unique images.
• The DOM is read once per image; data is read faster for subsequent requests for the same image due to being stored in the array.

Once again, it’s theoretical, but I think it would be the best approach. Naturally, only testing would confirm.

Memory is cheap, accessing the DOM is expensive. If you have 5,000 nodes in your gallery and the user is going to access a couple of them, then it doesn’t make sense to store 5,000 different objects in a JavaScript array.

If you have 200 nodes, and the user will access 50 or 60 of them, (or maybe all of them) then it makes sense to cache the information in JavaScript.

The memoization pattern suggested by Jermery is only useful if the user is accessing the same items again and again. GitHub is a good example of that. If HTML5 is an option, you may want to use the Cache Storage.

Lots of options, but if you can tell us about your users behavior, we can give better solutions

tsafi said
Yes what’s that 5000? You running a particle system i should know ?

lol I wish . The number doesn’t effect the tests because the loop is run inside the jsperf “setup”. So I used 3000 because I wanted the tests to do some work as far as grabbing data from the array.

jwmcpeak said
So I would do a combination of the two. As the data is read from the element, cache it in the array and then remove the element.

Terrific idea. I’m going to test this and report back.