Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large lagspike on server startup #2667

Closed
4 of 5 tasks
znepb opened this issue Dec 6, 2024 · 0 comments
Closed
4 of 5 tasks

Large lagspike on server startup #2667

znepb opened this issue Dec 6, 2024 · 0 comments
Labels
status:pending Pending acceptance or closure. type:bug Incorrect behavior, not working as intended

Comments

@znepb
Copy link

znepb commented Dec 6, 2024

WorldEdit Version

7.2.15

Platform Version

Fabric-Official(7.2.15+6463-5ca4dff)

Confirmations

  • I am using the most recent Minecraft release.
  • I am using a version of WorldEdit compatible with my Minecraft version.
  • I am using the latest or recommended version of my platform software.
  • I am NOT using a hybrid server, e.g. a server that combines Bukkit and Forge. Examples include Arclight, Mohist, and Cardboard.
  • I am NOT using a fork of WorldEdit, such as FastAsyncWorldEdit (FAWE) or AsyncWorldEdit (AWE)

Bug Description

On server startup, WorldEdit blocks the main thread for 17,140ms. This is likely caused by my server having some mods with large block/state counts (probably Consisteny+). However, it seems that WorldEdit caches all block state information on server startup on the main thread, causing a long time between the server saying it is ready to go and actually being ready to go.
Image
Image
Profiling via Spark

Expected Behavior

The server does not create a large lag spike on server startup.

Reproduction Steps

  1. Install Consistency+ on a dedicated server, or another mod with a large amount of blocks/block states
  2. Start the server
  3. Notice how long it takes between the server saying it is online, and it being available

Anything Else?

This could be easily fixed by running the block state collection on a secondary thread rather than the main thread.

@znepb znepb added status:pending Pending acceptance or closure. type:bug Incorrect behavior, not working as intended labels Dec 6, 2024
@znepb znepb closed this as completed Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:pending Pending acceptance or closure. type:bug Incorrect behavior, not working as intended
Projects
None yet
Development

No branches or pull requests

1 participant