Skip to content

Future Optimizations / Ideas #196

Closed
Closed

Description

@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

Activity

  1. changed the title [-]Future Optimizations[/-] [+]Future Optimizations / Ideas[/+] on Jan 22, 2021
  2. deleted a comment from github-actions on Mar 1, 2021
  3. removed
    staleIssue has been inactive for a while
    on Mar 1, 2021
  4. locked and limited conversation to collaborators on Mar 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    EnhancementNew feature, request, or thing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions