2 ms·
4500 queries per second per node doesn't sound like much. "100s" of linear polygon scans could likely turn into a few, plus a quad tree or spatial grid hash lo
by jwatte 9y ago
4500 queries per second per node doesn't sound like much.
"100s" of linear polygon scans could likely turn into a few, plus a quad tree or spatial grid hash lookup. I don't quite understand why those approaches are considered "complex?" Every simplistic game engine does this as soon as it implements collision.
Finally, choosing languages for workloads is fine. Python and JavaScript are famously non-threaded. But what about Java, C#, or C++?
And why is the index updated in process, instead of a new process spinning up with the new index, and then switching over who takes requests?
Not saying what they built doesn't work, just curious about options.
- quietbritishjim 9y ago> Finally, choosing languages for workloads is fine. Python and JavaScript are famously non-threaded. Python has famously misunderstood threading support. It is certainly single threaded sometimes (or rather multi threaded but only one can run at a time even on a multi core machine). But it can be usefully multithreaded if most of your computation is done with a C extension module that releases the GIL while it's being called e.g. numpy. If such a wrapper for the C++ S3 library exists (I haven't checked) it would be viable for this task. I agree that choosing languages for work loads is fine though, and admittedly even in the best case Python would still not be as efficient as Go.