⚡ Optimize roll_table using std::vector instead of std::map#9
Conversation
This changes the internal data structure of `roll_table` from `std::map<int, int>` to `std::vector<std::pair<int, int>>`, improving cache locality and reducing allocation overhead during construction. The `lookup` method was updated to use `std::upper_bound` with a custom lambda over the vector, mimicking the original behavior. The constructor was updated to use `.reserve()` and `.push_back()` while ensuring duplicate size indices only keep the latest insertion as `std::map::operator[]` would have. Performance tests showed ~36% improvement for roll_table on `perf_table_rolls`. Co-authored-by: perim <436583+perim@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
1 participant
💡 What: Replaced
std::map<int, int>withstd::vector<std::pair<int, int>>inroll_tableand usedstd::upper_boundfor lookup.🎯 Why:
std::mapcauses poor cache locality and high memory allocation overhead per node. Changing it to a contiguous block of memory (std::vector) drastically improves lookups through cache-friendly iteration and improves construction time.📊 Measured Improvement: Running
./build/perf_table_rollsin Release mode (-DCMAKE_BUILD_TYPE=Release) shows theroll_tablebaseline went from ~6.73 million cycles down to ~4.30 million cycles, representing an approximate 36% performance improvement for this data structure.PR created automatically by Jules for task 3800364742027521827 started by @perim