You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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?
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.
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: