Suggestion: change ChunkMap struct to use vectors instead of arrays

[highwaycoder]

This resolves the stack overflow issue when starting up on windows, because the ChunkMap gets allocated on the heap instead.

I do understand the performance implications of this change, but I'm curious whether any measurement has been done or if this is an example of premature optimisation? Are there any other ways to optimise the chunkmap that doesn't require allocating it all on the stack?

[finnbear]

In theory, we (or you editing the code) can easily solve the stack overflow by increasing the stack size of the thread.

Regarding performance, optimizing codegen is important. Rust/LLVM tend to output better assembly code throughout the program when the size is statically known and when there is less indirection. We haven't done this particular experiment, though.

Also, Stack Overflow? Do you mean GitHub (#7)?

[highwaycoder]

Yeah I understand the theory behind why it's more performant in general, was just curious whether there was a specific case study done as I would personally always default to heap allocation until and unless performance becomes an issue, premature optimisation being the root of all evil and all.

I mean literal stack overflow, not StackOverflow the website. I wasn't aware of an existing issue covering this topic, sorry - I glanced through them but on that issue I thought the issue in the title was the only issue mentioned, reading back through I see the stack overflow thing is mentioned as well 😅 feel free to close this one as a duplicate.

Absolutely not trying to start any philosophical debates, was just trying to see how I could fix it to run on windows for my own testing purposes (I've only got my windows laptop with me this week) and whether the work I did/am doing on that would be of any value to the project or not -- all good if not, I can understand and empathise with the "performance at any cost" mindset (probably this project isn't for me if that's the case though)

[finnbear]

We host hundreds of concurrent players on $5/mo single shared core + 1TB free bandwidth VPS's from Linode.

Our old Go implementation of a comparable game (Mk48.io) supported less than half as many players per server, and the multi-core hardware it required cost us $100/mo (not to mention $200/mo for bandwidth).

We take any performance we can get, and don't see the problem bumping up stack size on Windows to make this particular issue go away.

I would have done it already, except that we haven't done an open-source release (copying private repo to public repo) for Kiomet recently.