-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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 Color::find_named_color()
#75860
Optimize Color::find_named_color()
#75860
Conversation
This and your unicode pr makes me think that we should maybe introduce a proper binary_search function that takes a three way comparison and return the complement of the would be index when not found, to for cases like these where information about the existence of the value is also reqired and the existing bsearch function is not useful. |
04bf446
to
e129c85
Compare
e129c85
to
200ace4
Compare
This should probably just use some kind of You could probably have a collision free hash even with the duplicates. Also this kind of stuff should likely be parsed once then reused on subsequent frames, so there's only a cost if the text is constantly changing. I'm assuming this is the case, but I haven't read any of this code. |
200ace4
to
dd82146
Compare
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't tested but LGTM
dd82146
to
49594d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The optimization looks good.
I'm a bit puzzled at the general implementation of that feature though, it feels pretty convoluted, especially with the "normalization" done to support apparently arbitrary variants like "yel_lo.w'G R'-een"...
Seems like unnecessary complexity, but well, changing it now would break compat.
With a simpler design, we could just have a hashmap for the colors directly instead of storing an intermediate map of indices.
Thanks! |
Use binary search instead of linear.
Note that GDScript already caches constant values, unlike
RichTextLabel
. If we still decide to use aHashMap
, then we need to store two names (for example,ALICE_BLUE
andALICEBLUE
), since the name with underscore is needed for constant binding.