-
Notifications
You must be signed in to change notification settings - Fork 42
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
Comments
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 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? |
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. |
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. |
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 Could you submit a PR for this? I would really appreciate it! |
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. |
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:TagIDs
with correspondingHasTagIDs
and related funcsI 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).
The text was updated successfully, but these errors were encountered: