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
5 files changed