CODEWITHSUNDEEP
javascriptmemory-management
Joshua Foxworth
Joshua Foxworth

Reputation: 1397

Javascript - Script Memory vs DOM Storage

I am writing a code that solves equations for users. The user will be able to enter matrices, vectors and such. Right now, as I solve those equations, I write the solution to a table with each row representing any given variable or equation. The javascript object that was used to hold the equation during calculation is destroyed. I did this on purpose to prevent large arrays of data being stored in memory and potentially slowing down the script. As an array is needed later, it is read into an object from the appropriate table row.

I am wondering how holding memory in the DOM like this compares to holding it in objects in memory. I am more at risk to slow down my code execution by holding these things in memory as objects instead of on the DOM? Also, since these objects will need to be accessed by multiple parts of the code, these would have to be global objects. Right?

Upvotes: 2

Views: 1721

Answers (2)

josh3736
josh3736

Reputation: 144902

In a word, no.

There's one rule that is a constant in web development: the DOM is slow.

Selecting, accessing, and iterating DOM elements and reading and modifying their properties is one of the single slowest things you can do in browser JS. On the other hand, working with native JS objects is very fast. As a rule, I avoid working with the DOM as much as possible.

You make the (incorrect) assumption that low memory usage somehow equates to improved performance. In fact, it is generally1 (and not just in the browser) the case that increased memory usage increases application performance. By the nature of having calculated results cached in memory, you avoid the processor- and time-intensive need to rebuild data at a later time. Of course, you must balance your use of memory with the need for performance.

In your case, I'd definitely keep the equation object in memory. It's probably using a surprisingly small amount of memory. For example, I just created an array of 1,000 integers in Chrome, and the memory profiler told me that it used less than 40 kB – almost all of it object overhead. The values themselves only took 4 kB – 1000 * 4 bytes (32 bits).

When you consider that the routines that read the DOM to regenerate the object probably take tens to hundreds of milliseconds (or much worse, depending on complexity) to run, why wouldn't you just generate the object once and keep it, especially since the cost is so low?

However, as with all performance questions, the real answer is that you have to profile your application to see where the performance bottlenecks really lie. Use Chrome's Developer Tools' Profiles tab to take CPU profiles (which measure processor utilization over time) and heap snapshots (which measure memory usage in an instant) as you use your app.

1 - This really depends on whether your program uses so much memory that pages must be swapped out. On desktop machines where 16 GB of RAM has become commonplace, you have nearly nothing to worry about. However, it is still important to watch memory usage on mobile devices where resources are more constricted.

Upvotes: 4

RobG
RobG

Reputation: 147363

I am wondering how holding memory in the DOM like this compares to holding it in objects in memory.

Test it and see, I'd expect the DOM to use more memory and be very much slower to access. In any case, unless you are storing an awful lot of stuff the memory implications are likely minimal.

I am more at risk to slow down my code execution by holding these things in memory as objects instead of on the DOM?

The opposite I expect. Accessing the DOM will be very much slower.

Also, since these objects will need to be accessed by multiple parts of the code, these would have to be global objects. Right?

Wrong. You can hold references in a closure, or put all the objects into a single array or object. In any case, global objects aren't bad per se, they are just considered untidy and increase the chance of name collisions.

Upvotes: 1

Related Questions