I do appreciate the effort the author put into that library and obviously performance is important.
However, JS doesn't primarily live in the server side world, it mostly lives in the browser world. 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.
You're also doing it wrong in you are relying on server side NodeJS for tasks that involve heavy duty computations.
Still, interesting to know. I wonder if the author can make this repo a proposal to the TC39 committee.
I consider this wrong on all counts and I don't see where you're coming from to make these claims. You obviously benefit from performance gains on the server and client in standard use-cases.
A Node.js server's main thread is nickel and dimed by a thousand little cuts. A faster hash implementation can reduce loop delay by a nontrivial amount. This isn't heavy processing.
Same with the client. Any sort of game could have a good reason to be doing hashtable lookups in a hot loop on the client. This isn't heavy processing in some exotic use-case, it's rather elementary. And perf trade-offs especially help slow clients. And freeing up the main thread lets you fit in more nonreducible cycles.
Also, moving work to the server because your client implementation is too slow and then generalizing that to "always do work on the server", is tautological. Where you do work is fundamentally a business logic / product design concern that is only a performance concern in the suboptimal case where you can't fit the work on the server or client. So faster implementations move what are performance concerns back into the realm of higher level product design decisions.
These aren't symptoms of "doing it wrong". This is just plain jane software engineering.
> 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.
> 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]
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.
> 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?
It'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.
One of the selling points of tensorflow.js is that you do your processing on the client, for privacy reasons. This is heavy, heavy processing, and you're doing it right.
However, JS doesn't primarily live in the server side world, it mostly lives in the browser world. 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.
You're also doing it wrong in you are relying on server side NodeJS for tasks that involve heavy duty computations.
Still, interesting to know. I wonder if the author can make this repo a proposal to the TC39 committee.