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

Increase chunkloading speed #3804

Merged
merged 2 commits into from Jan 20, 2020
Merged

Conversation

@DarkWeird
Copy link
Contributor

DarkWeird commented Dec 14, 2019

Contains

Increase chunk loading speed for client and server (not world generation).
Maximum effect should be visible on SSDs. Or in multiplayer with 6+ players who are far apart

  • Seems, fix zombie thread, that prevent close client. (maybe #3738)

How to test

Chunks:

  1. Open Terasology
  2. Load world, which chunks generated with max view distance
  3. try compare chunkloading speed before and after (load world before using PR and after)

Thread:

  1. Open Terasology
  2. Open Mutliplayer
  3. Close Terasology( you can exit from JoinServerScreen)
  4. You haven't Terasology process in Task Manager/top/htop/etc
Seems, fix zombie thread, that prevent close client.
@GooeyHub

This comment has been minimized.

Copy link
Member

GooeyHub commented Dec 14, 2019

Uh oh, something went wrong with the build. Need to check on that

@GooeyHub

This comment has been minimized.

Copy link
Member

GooeyHub commented Dec 15, 2019

Hooray Jenkins reported success with all tests good!

@eviltak

This comment has been minimized.

Copy link
Member

eviltak commented Dec 31, 2019

Thanks for the contribution @DarkWeird! Can you elaborate on how (why) these changes improve chunk loading times?

@DarkWeird

This comment has been minimized.

Copy link
Contributor Author

DarkWeird commented Dec 31, 2019

@eviltak
Before:

  1. Chunk generated or loaded from disk: it's not ready for rendering and interact
  2. Chunk put in LightMerger
    2.1. LightMerger uses singleThreadPool with "one slot job"(Future Variable)
  3. ChunkProvider checks chunk is ready in LightMerger via Future(almost true) and mark it ready.
    Its takes 2 ticks for one chunk.

After:

  1. Some chunks generated or loaded from disk
  2. All these chunks put in LightMerger
    2.1. LightMerger uses singleThreadPool with queue of jobs
  3. ChunkProvider get all ready Chunks in LightMerger and mark it ready.
    It's takes 2 ticks for many chunks.

Its was looks like bottleneck.
I could do the processing in more than one thread, but not sure about the thread safety of the algorithm

Copy link
Contributor

Qwertygiy left a comment

My testing showed little to no apparent changes in singleplayer, but I have a mixed SSD/HDD and a decent CPU, so I would not be squeezing through the bottleneck that this should clear. At the very least, it verifiably does not make anything any worse in normal singleplayer chunkloading for me, and the code style looks to be an improvement.

@Qwertygiy Qwertygiy merged commit d3fb11c into MovingBlocks:develop Jan 20, 2020
2 checks passed
2 checks passed
LGTM analysis: Java No new or fixed alerts
Details
default Build finished.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.