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

Optimized Tags #21

Open
kettek opened this issue Apr 27, 2023 · 5 comments
Open

Optimized Tags #21

kettek opened this issue Apr 27, 2023 · 5 comments

Comments

@kettek
Copy link

kettek commented Apr 27, 2023

In relation to PR #20, HasTags has ended up being one of the heaviest function calls in resolv. In terms of optimizing this, would it be possible to introduce using either:

  • A tag field like TagIDs with corresponding HasTagIDs and related funcs
  • Use generics to allow overriding the tag type
  • Some other smarter idea

I have no problems implementing either one myself. Generics would be more performant, but would introduce some complexity and potential API changes (might be able to "wrap" the second problem, but not certain yet).

@SolarLune
Copy link
Owner

SolarLune commented May 8, 2023

I think I'd like to avoid generics for now considering this is a relatively low-level API, where it should slot in to various build systems - I'd imagine most would have a recent enough version of Golang to allow this, but I'd like to be sure. How would generics make HasTags() faster? Is it because tag names are strings - would it be faster to use non-string tag types?

Also, is there another way on your side to optimize, perhaps by simply assigning an object to a particle collider's Data, and then checking that type?

@kettek
Copy link
Author

kettek commented May 9, 2023

String comparisons are slower than most other basic type comparisons. This compounds very quickly with 60 TPS and more than a handful of physics objects.

As far as ignoring the tags and using my own data structure for comparison, that would probably do the job just fine.

@thegrumpylion
Copy link

A better solution for optimizing tags is to use an unsigned int and test using bit operations. I use this library for my games and I implemented a proof of concept here https://github.com/thegrumpylion/resolv/tree/bit-tags . The limitation is that you can only have as many tags as the bit size of the unsigned int. Since I am using a uint64 you can have up to 64 layers/tags.

You can define your tags like this https://github.com/thegrumpylion/resolv/blob/225fdbfd4729514cfedaad707807a2dd452bba7d/examples/main.go#L19

Another thing that changes for performance gain, is that you should use bitwise OR when addressing multiple tags (case in point https://github.com/thegrumpylion/resolv/blob/225fdbfd4729514cfedaad707807a2dd452bba7d/examples/worldPlatformer.go#L254)

If this library is interested in a change like this I can create a pull request. If not, I'm fine with keeping my own fork and thank you for this great tool.

@SolarLune
Copy link
Owner

If this library is interested in a change like this I can create a pull request. If not, I'm fine with keeping my own fork and thank you for this great tool.

Hello - this does look like a better solution, especially since it automatically works with multiple tags without needing variadic arguments, and 64 tags sounds like an acceptable amount; if more were necessary, the user could just implement their own tagging system tied to objects placed in each Object's data field.

Could you submit a PR for this? I would really appreciate it!

@SolarLune
Copy link
Owner

SolarLune commented Oct 30, 2024

Actually, never mind - I think I'm going to refactor the entire library to be both easier to use as well as more efficient when it comes to tag usage. Thank you very much for the thoughts; I'll probably just adjust the tags to be bitwise properties.

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

No branches or pull requests

3 participants