Future Optimizations / Ideas

[Iapetus-11]

List of optimizations (to maybe be implemented later) to make PyMine fast!

World pre-generation

• Each region or group of chunks to be generated handled by a separate process
• Easily parallelized via multiprocessing
• Benefits:
  • Faster world/chunk times for the pre-generated chunks
  • Less strain on the server later on
• Drawbacks:
  • Would probably render the server super laggy when active
  • Only works for a specified area
  • Could possibly waste disk space if that area isn't used

Groups of players handled each by a separate process

• Backend process which handles world gen, global events, etc...
• Every group of 3-5 players is handled by a separate process
• Benefits:
  • Faster server response times and packet handling
• Drawbacks:
  • Clunky + jank code to synchronize data between processes
  • Probably not worth it with groups so small or on crappier machines

Dynamic world generation

• Similar to world pre-generation
• When resources are free, pre-generate chunks around a player even if they're not attempting to load not-yet-generated chunks.
• Benefits:
  • Faster chunk/world load times for players in the area
  • Possible less strain on the server if the server were to need those chunks to be generated in the future
• Drawbacks:
  • Possible shortage of resources if resource usage suddenly spikes
  • Waste of disk space if chunks that are generated are never used

Unused chunk degenerator

• When ran, would delete chunks that were left completely unchanged
• Easily parallelized via multiprocessing
• Benefits:
  • Could reduce amount of used disk space
• Drawbacks:
  • Could increase server strain later on when those chunks are used again
  • Not worth it unless disk space is scarce

Separate processes for loading/dumping chunks/regions

• A full-ish region (from Xenon) takes about 6 seconds to load, and it'd probably take just as long to dump.
• Loading/unpacking a region file is also very CPU intensive, which would BLOCK the event loop
• Actually reading/writing the file from the disk also blocks the event loop
• Benefits:
  • Reduces server lag
  • Makes chunks faster to load (maybe)
• Drawbacks:
  • Hard to implement well

Custom Region Format

• Consists of 1024 chunks just like the normal format
• Has a location table, just like the normal format
• Each chunk has a header of a 4 byte int that says how long it is
• The entire file is zlib-compressed, rather than each chunk section
• Region file is named mostly the same, except the file extension is .mcpyr or something else idk
• Benefits:
  • Less space used to store a region (a 32x32 section of chunks)
  • Less calls to zlib.decompress()
• Drawbacks:
  • Not compatible with normal worlds / region files
  • We would need to support two region file formats