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

Optimize Cache lookup #1993

Merged
merged 4 commits into from
Dec 21, 2019
Merged

Optimize Cache lookup #1993

merged 4 commits into from
Dec 21, 2019

Conversation

mateofio
Copy link
Contributor

No description provided.

@mateofio
Copy link
Contributor Author

mateofio commented Dec 20, 2019

This one also makes a measurable improvement in Frozen triggers. 2% of frame time is spent in std::map lookups.

Without this PR
cacheold

With this PR
cachenew

@mateofio
Copy link
Contributor Author

Adding constexpr for Spec yields more small improvements.

constexprcache

@mateofio
Copy link
Contributor Author

After removing the async check.

cache-nocheck

@mateofio mateofio force-pushed the cache branch 2 times, most recently from 2b42f9c to 07e6867 Compare December 21, 2019 03:18
@mateofio mateofio added the Performance Related to improvements on memory, less CPU or disk usage, battery savings, etc. label Dec 21, 2019
@Ghabry
Copy link
Member

Ghabry commented Dec 21, 2019

Could you discuss the advantage of "hash key via string concat" vs "hash key as tuple"?

@mateofio
Copy link
Contributor Author

mateofio commented Dec 21, 2019

The real win here is switching from tree based map to hash based unordered_map.

As for the difference between building a composite string vs hashing tuple elements, that would need to be profiled to get a definite answer.

Unfortunately both idioms require string copies, but it's possible the tuple version uses shorter strings more and so we could trigger the small buffer optimization more often and avoid calls to malloc(). Offset that with multiple calls to your hash function instead of hashing one buffer in a single call.

The standard library doesn't support arbitrary hashing of tuples, for that we would need something like boost::hash_combine. That's the reason I did the composite string approach.

Copy link
Member

@carstene1ns carstene1ns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@Ghabry Ghabry added this to the 0.6.2 milestone Dec 21, 2019
This check causes a measurable slowdown in I/O heavy games.
Use an assert() instead.
Also add some inlines
@Ghabry Ghabry merged commit bff3d12 into EasyRPG:master Dec 21, 2019
@mateofio mateofio deleted the cache branch January 16, 2020 03:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Performance Related to improvements on memory, less CPU or disk usage, battery savings, etc.
Development

Successfully merging this pull request may close these issues.

3 participants