https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563
--- Comment #8 from andi at firstfloor dot org --- > > Needs a workload where it matters > > PR119387 had > > 85.81% 1500713 cc1plus cc1plus [.] > ggc_internal_alloc(un > > for me. Can we keep an index to freelist from allocation order to avoid > the linear search? Yes for the alloc > Other than that the patch looks simple than I thought, > and it definitely resolves an algorithmic complexity issue, so even without > a clear workload where it matters it should be OK (during stage1, that is). The main drawback is that the madvise patterns to the OS are worse because it will do it in smaller chunks. That was the reason I had second thoughts later.
