Repository navigation
Future Optimizations / Ideas #196
Copy link
Copy link
Closed
Labels
EnhancementNew feature, request, or thingNew feature, request, or thing
Description
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
.mcpyror 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
Metadata
Metadata
Assignees
Labels
EnhancementNew feature, request, or thingNew feature, request, or thing
Activity
[-]Future Optimizations[/-][+]Future Optimizations / Ideas[/+]