-
Notifications
You must be signed in to change notification settings - Fork 491
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
Custom message improvements #2892
Custom message improvements #2892
Conversation
Should result in much fewer allocations when rendering custom messages during a Randomizer playthrough.
This should allow for fewer allocations during randomizer seed generation and runtime, plus a couple of other enhancements that utilize custom messages. It does this by taking advantage of move semantics to prevent extraneous allocations when string literals are passed in. It also takes advantage of OOP to hopefully end up with a cleaner API.
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.
Overall this looks great! Assuming this has been tested I'm close to saying !
Left one little naming comment in there but otherwise this is awesome!
Assuming I'm using Visual Studio's profiler correctly, after seed generation we seem to have dropped about 200 string allocations with this PR. |
This PR contains what I think is a cleaner API for Custom Messages, and implements some move semantics so there should be fewer string allocations.
CustomMessage
class to replace theCustomMessageEntry
s with something utilizing better object oriented design. This class should also properly utilize move semantics to prevent unnecessary string allocations when provided string literals orconst char*
sReplaceStringInMessage
methods from theCustomMessageManager
and moves its functionality to the newCustomMessage
class'Replace
functions.CustomMessage
, such as capitalization.CustomMessageManager
was used, replacing some unnecessarily heap allocated structs with stack-allocated ones (i.e. std::vector to std::array, or moving an array into the function where it was used.I would appreciate if someone could assist me in getting some sort of profiling going to verify that the claims about less allocation are true. I don't quite know how to check for that unfortunately.
Build Artifacts