search for: code_size_increase

...es here IIUC: However it is likely that we could consider these “small” benchmarks should use -Os if they're sensitive to size, and so O2 would be fine with the more aggressive threshold (as larger program aren’t affected). With good heuristic we’d have every dot forming a straight line code_size_increase = m * runtime_perf (with m as small as possible). The current lack of shape (or the exact opposite distribution to the ideal I imagine above) seems to show that our "profitability” heuristics are pretty bad and the current threshold knob is bad predictor of the runtime performance. — Mehdi...

First off, I just want to say wow and thank you. This kind of data is amazing. =D On Thu, Feb 16, 2017 at 2:46 AM Kristof Beyls <Kristof.Beyls at arm.com> wrote: > The biggest relative code size increases indeed didn't happen for the > biggest programs, but instead for a few programs weighing in at about 100KB. > I'm assuming the Google benchmark set covers much bigger