[PATCH] Refactor VariantMatcher::MatcherOps to reduce the amount of generated code.

[Rafael Espíndola]

On 2 September 2014 11:34, Samuel Benzaquen <sbenza at google.com> wrote:
> I did try splitting it up. It doesn't scale much.
> Each part contains duplicate template instantiations, so splitting in N pieces will not make each one 1/Nth of the total.
> Tried 1-5 pieces. These are the results:
> # parts | # symbols | total #
>         |  per part | symbols
>     1   |    ~19k   |  ~19k
>     2   |    ~13k   |  ~26k
>     3   |    ~10k   |  ~30k
>     4   |    ~9k    |  ~36k
>     5   |    ~8k    |  ~40k
>
> Note that I did not try to group similar matchers together (which would be a maintenance nightmare), so each part ends up instantiating most of the common templates for a lot (most?) of the node types.

What is the compile time impact? In particular, how slow is the
slowest one after the split compared with the original?

Cheers,
Rafael