tree 6f57257bc4205328aff0b7fb8d16f8945dea722c
parent 20e1ebb6d7b9959971baf0903beb0c7f7169e716
author buzbee <buzbee@google.com> 1327530194 -0800
committer buzbee <buzbee@google.com> 1327539397 -0800

More compilation performance tuning

A man walks into a doctor's office and says:
   "Hey Doc, it hurts when I do this"
Doc says:
   "Then don't do that"
...

Although the last round of tuning the dataflow analsis code
resulted in a large speedup, we are still faced with a
significant number of (primarily initializer) methods which
blow up into a large number of basic blocks.  We spend
much time and memory uselessly analyzing these (both because
they aren't run enough to matter, and even if they were, there
isn't much optimization we can do).

This CL attempts to recognize such methods, and skips the
most expensive analysis.  The worst-case application that
we've been looking at gets a 35% boost in compilation speed,
but perhaps more significantly, the compiler's peak heap
usage drops from 370M to 162M.  (Note: even 162M is much too
high - I'll be looking at further reducing worst-case memory
usage next).

Change-Id: I93cd15c846043cf46860afa562957921fc2de464