When does a JSON object become a burden on memory? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 years ago.

Improve this question

I'm developing a single page application where the first page contains the subjects and the next one contains items of the chosen subjects. The items are stored in a JSON object fetched from the server and have only two properties - name and id.

My questions is - generally speaking - should I divide my fetch from the server to two separate requests - first one for the subject, and second for the items of the selected subject, or might it be good to fetch everything in once?

Obviously it depends on the quantity of the items in each subject. And I know that fetching a large object will take more time to fetch and also more memory for the client to store the object in. But what would be a good rule of thumb? If I have in sum 200 items (names and ids), is it considered a lot already? or 400? How should I decide?

Answer 1

There is no general rule, but here's a suggestion.

• Retrieve everything in one request unless the retrieval and loading takes too long.
• If it's awkward to retrieve in one request and you would save significant development time adding a second request, do it and move on.

That's a good starting point (but not always the right long term answer). If it's taking too long then it's worth worrying about breaking it up.

Why?

Check how much memory the browser uses before you retrieve this data (usually 200-1500MB on Windows or Mac OS, Chrome or Firefox). Now ask what percentage you are adding to the storage.

If your items take 1MB in serialized form. That's insignificant in a browser process that's probably already using 200MB to 1000MB.

But 1MB can be noticeable as a download, depending on network conditions.

Network Requests are often significant to user experience.

• If you don't have better information then consider assuming a range of 50ms to 250ms for each request round trip (assuming server response is near instantaneous).

  Where I'm sitting right now I get a 5ms round trip to the nearest Google server, 75ms round trip to the nearest amazon.com server, 170ms round trip to a favorite server in Europe. Some cases are routinely worse, e.g. pacific islands.

• At the low end of that range 50ms, 400 requests is 20 seconds. That's why you don't want to retrieve each individual item in a separate request.

• Retrieving categories in one request and items in a second request may not be significantly different for users to notice.

• One more factor to consider. With mobile users and users in rural parts of the USA, island locations, and other 'remote' locations, interruptions are common, so the comfortable round trip rate you get in a major city often degrades to a slower rate with occasional long delays and gaps.

• So every additional request you add increases the opportunity for users to wait for network congestion or delays. That's a subtle point, but in some applications it makes a significant difference.

And Don't Forget The DOM

While 1MB may be insignificant to the OS and hardware, it can be enough data to really waste time in the DOM, if you are not careful with it.

DOM Rendering, like network requests takes a lot of time and resources compared to deserializing a simple structure into Javascript objects.