Hello, > > The problem is, that it does not give any speedups (it is almost > > completely compile-time neutral for compilation of preprocessed > > gcc sources). I will check whether moving also edges to pools > > changes anything, but so far it does not seem very promising :-( > > Well, the benefits of these things are always very dificult to predict > :(. We later tweaked ggc-page to put basic blocks into > extra_order_size_table that ight've improved locality and get back some > part of the original 1% slowdown. > > I would expect edges to be more interesting since they are smaller and > there are more of them but I might be mistaken.
at least for the preprocessed gcc sources, this turns out not to be the case. I guess there are two other reasons why we do not see the expected gains: 1) previously we kept only one cfg at a time (so using pool meant that the same memory was reused for each function), while now we keep cfgs for all functions alive at the same time. 2) garbage collection now needs to traverse basic blocks and edges (through the dynamic roots), while previously it did not see them at all. Zdenek
