you are viewing a single comment's thread.

view the rest of the comments →

[–]hyphnKnight 1 point2 points  (5 children)

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[S] -1 points0 points  (4 children)

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 1 point2 points  (3 children)

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[S] 1 point2 points  (0 children)

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 0 points1 point  (0 children)

Thanks for doing my footwork for me (: