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

[Samuel Benzaquen]

On Tue, Sep 2, 2014 at 11:39 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> 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?
>

In the 5-way split the compile time was about 60% (of the non-split
version) for each file. So if you run them in parallel you could do it in
40% less time, but you end up doing 3x the work.


>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140902/f301df8b/attachment.html>