3 ms·
> And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server. This is very incorrect. At m
by _bxg1 6y ago
> And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server.
This is very incorrect. At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. JavaScript did this just fine, and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server.
Even in this extreme use-case, the bottleneck was always the few-hundred items that were actually rendered in the DOM at a time. We virtually never had performance problems from sheer volume of underlying data.
- game_the0ry 6y ago> At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. The author's example inserts 4M elements. > and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server. Possibly, but unless you benchmarked both scenarios, this might not be the case. Performance over networked devices often has trade offs, sometimes those trade offs are directly contradictory, eg sorting/filtering/mapping/etc data on client side versus server side via api call - sometimes one is better than the other but you wont wont know unless you benchmark. I get the impression that your company did not go through that exercise, considering you guys are building an IDE with scripting language.[1] [1] https://nickjanetakis.com/blog/switching-to-vscode-from-sublime-text#:~:text=Performance,an%20i5%203.2GHz%20CPU.&text=CTRL%2BP%20searching%20is%20slightly,or%20getting%20in%20the%20way https://nickjanetakis.com/blog/switching-to-vscode-from-subl....
- jorangreef 6y agoWe actually use this to insert 400M elements. The only reason the example inserts 4M elements was because Set and Object start to become prohibitively slow at some point and crash the process with too many allocations, not to mention the stress on the GC which now has to follow so many pointers. HashTable performance is a fundamental component of any language.
- game_the0ry 6y ago> HashTable performance is a fundamental component of any language. Agreed, but why use Node if performance was so critical to your use case? Could this 400M insert logic exist in a separate service that lives outside your Node code base?
- _bxg1 6y agoIt's one thing to write a web service in a different language for performance; it's a much bigger question to move logic from your client to your server for the sake of performance. Both from a user experience standpoint and from an architectural complexity standpoint.
- game_the0ry 6y agoNot sure what you're getting at. Could you elaborate?
- deleted 6y ago[deleted]