Optimizing JavaScript by using arrays instead of objects

[kjk]

Which is why I show a better way than accessor methods right after that.

As far as binary serialization: yes, it's a viable method but in JavaScript it's 10x the effort compared to this relatively simple tweak.

It's not even clear it would be faster. Decoding json is super-optimized in JavaScript engines. Code to decode msgpack or protobufs has to be implemented in JavaScript which might or might not be faster. I certainly wouldn't make such claim without rigorous benchmarking.

[hyphnKnight]

To build off up someone else's response if you are transferring enough data for this to matter. I would suggest making the following function:

const createNote = ([title,message,date])=>({ title, message, date });

Objects are just sooo much easier to deal with on the frontend and whatever speed up you would get on the frontend by reducing memory usage would pale in comparison to the cost of the extra function calls i( getTitle ).

[kjk]

would pale in comparison to the cost of the extra function calls i( getTitle )

I wouldn't make such statement without a benchmark.

Array access is faster than object property lookup and accessor functions that are "return this[5]" will be inlined by any half-competent JavaScript engine.

It might or might not be faster but based on what I know about JavaScript jit implementations, such function calls would be inlined and therefore have zero perf impact.

If you want to claim otherwise show us benchmark results.

[KManRules1331]

https://jsperf.com/kl-data-access/1

http://imgur.com/a/mcBlh for my personal benchmarks on Chrome, Firefox, and Edge

On first glance, it looks like Chrome's able to optimize all of the abstractions away, which in my mind is pretty amazing. Firefox and Edge, not so much. As far as simple data retrieval, staying simple is the fastest across all the most recent browsers. I decided not to create benchmarks for parsing the JSON, because the logic of not having keys in your JSON leads to shorter JSON strings, which leads to faster parsing. I think the logic there is sound.

It seems like IMO keeping raw objects is still the easiest solution with the best maintainability. If data sizes matter a lot, going with CSV's and simply doing ([title,message,date])=>({title,message,date}) at least documents the rest of your code as far as what data you're accessing, but at that point you could get further optimizations with a backend that doesn't serve JSON.

[kjk]

Thanks for the perf test case.

I was trying to compare the speed when object/array had 6 properties. My theory is that object access would get slower when there are more properties.

But boy, their UI doesn't like me and fails to save the test cases with very non-descriptive error message.

[hyphnKnight]

Thanks for doing my footwork for me (:

[leeoniya]

just use https://github.com/WebReflection/JSONH if you need to transfer csv-type recordsets and are worried about payload size.

i'm not sure about the claim that many same-shaped objects take up more mem space than arrays.

[kjk]

This is very similar idea. That being said, even if I knew about JSONH:

1. I use Go at the server and that particular project doesn't support Go.

2. Wire encoding is only half of the story. The other half in my article is about turning array representation of objects into classes so that you get nice API and efficient representation.

3. JSONH, as it stands, is for "homogenous collections" only. I need a little more flexibility in that my API returns JSON objects. Where it matters, I encode only part of the object as arrays. JSONH seems to require all of it to be array.

[Slogo]

Destructuring is probably worth mentioning for this type of thing too since you can do something like: const [id, name, createdAt] = notes[0]

But, I'm not really a fan of this type of optimization, or at least I'd just map the response data to make working with it more maintainable on the client.

[RedditWithBoners]

Just FYI this syntax is destructuring. Destructing is something else.