6 ms·
I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing ph
by johnwheeler 3y ago
I don’t see why. Connection-wise, the node event would loop make I/o blocking from the http request / response side a non issue. I doubt the backend is doing physics heavy stuff for the front end.
- deadbabe 3y agoYou must perform physics calculations on the backend if they are significant features that influence player positions. Node also only works off a single core.
- johnwheeler 3y agoI see. That makes sense.
- nine_k 3y agoNode of course can work on multiple cores, using worker threads [1]. You can even share large data efficiently using a SharedArrayBuffer. [1]: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
- moffkalast 3y agoThere is still considerable overhead turning things into buffers and back. Was there ever a good reason given as to why passing an object to a worker normally has to convert everything to string and back? It is just so completely idiotic.
- deadbabe 3y agoIt isn’t trivial to just split up a game into múltiple worker threads and keep everything in sync. With Go, it’s much easier.
- holografix 3y agoCan you expand on the low hanging fruit of splitting a game into multiple goroutines? What lends itself well to this?
- deadbabe 3y agogoroutines