This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch] Use a std::vector instead of a std::map to hold Input_merge_map
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Rafael EspÃndola <rafael dot espindola at gmail dot com>
- Cc: Sriraman Tallam <tmsriram at google dot com>, Binutils <binutils at sourceware dot org>
- Date: Mon, 1 Jun 2015 15:45:47 -0700
- Subject: Re: [patch] Use a std::vector instead of a std::map to hold Input_merge_map
- Authentication-results: sourceware.org; auth=none
- References: <CAG3jReK3HdZfV7R6Kp_ijWX0UF6EoNuZdFN2XJQ=jLNWBp0fwQ at mail dot gmail dot com> <CAG3jReLNg36sZDiJYTK-zDV1RwyMLadHHpJEbgc7VJUzFP=aOQ at mail dot gmail dot com> <CAAs8HmxUhzB6aURTQJVybyypa5t80pHG3Z15vc8vggdogmn6LA at mail dot gmail dot com> <CAG3jReLrb==2h6vSQKM5nNHdQn4vPLRwN5COD89Mwi8mSFc6yA at mail dot gmail dot com>
>>>> A std::map is hardly the best data structure for a small map from
>>>> small integers.
>>>>
>>>> The attached patch uses a std::vector<std::pair>> instead.
>>>>
>>>> This simplifies the code and speeds up linking of chromium (see
>>>> attached perf logs).
Yes, it seems like the original assumption that object files would
rarely have more than 2 merge sections is outdated.
Out of curiosity, did you try using an Unordered_map instead of
std::map? (While also removing first_map_ and second_map_.) I wonder
where the break-even point is between using a hash map and a linear
search.
> 2015-04-23 Rafael Ãvila de EspÃndola <rafael.espindola@gmail.com>
>
> * merge.cc (get_input_merge_map): Update for data structure change.
> (get_or_make_input_merge_map): Update for data structure change.
> * merge.h (Object_merge_map): Use a std::vector<std::pair>> instead of
> a std::map.
Please add a note in the ChangeLog entry about removing first_shnum_, etc.
This is OK. Thanks!
-cary