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

Optimize AngleMask #3072

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Optimize AngleMask #3072

wants to merge 4 commits into from

Conversation

SirYwell
Copy link
Member

Overview

Description

AngleMask caused unnecessarily slow block lookups due to its access patterns. That can be improved. I'll add some inline comments about specific changes.

Submitter Checklist

Preview Give feedback

@SirYwell SirYwell requested a review from a team as a code owner January 10, 2025 08:51
return true;
}
if (!mask.test(extent, mutable.setComponents(x, y, z + 1))) {
// other positions might be in different chunks, go a slower, cached path there
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially worth coming back to this after the merge of this and #3051 - if the cache performance is still poor then probably worth testing if x/z are actually on the edges of the chunk. Maybe this could be implemented into the cache mask constructor - we can potentially look at ways of compressing the data further.

}

@Override
public boolean test(BlockVector3 vector) {

if (!mask.test(vector)) {
if (!fastMask.test(vector)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should cache this at least if on the edge of the chunk, as there's little point using the cache mask on x/z +/- 1 if there's unlikely to be a value already in the cache. We know we're going to be testing every block here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's worth the complexity to have different code paths for those cases. I tried again to revert this change to use the cached mask and it makes the whole mask slower even in the overlay scenario.

I also replaced the usages of the CachedMask in adjacentAir, bringing time spent in adjacentAir down from ~25s (when using the cached mask everywhere) to ~10s in my test... so I guess we really need to look into CachedMask after your PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay that's definitely concerning then. I suppose the caching makes it slower if the chunks are already available, and we will already have those GET chunks loaded in FAWE

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that code path doesn't seem to run into chunk loading, so any access is more or less direct (going through STQE)

Copy link

Please take a moment and address the merge conflicts of your pull request. Thanks!

@SirYwell
Copy link
Member Author

After #3051 got merged, it still seems to be a performance win avoiding the CachedMask usage completely:
comparison (old is the current state of this PR, new is replacing the remaining usages of mask with fastMask.

@dordsor21
Copy link
Member

I suppose it's probably worth removing the CachedMask in this case entirely?

@SirYwell
Copy link
Member Author

I think so, yeah. Maybe it also comes down to how chunks are spread across threads, that might make caching values of surrounding chunks less useful too.

The CachedMask field is protected, do you think it's still fine to remove it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants