http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #22 from Mark Mitchell <mark at codesourcery dot com> 2011-01-06 03:55:40 UTC --- On 1/5/2011 5:36 AM, hubicka at gcc dot gnu.org wrote: > 40259 5.6000 cc1plus cc1plus > lookup_field_1 I've looked at this, in the distant past. I don't think the routine itself is *very* low-hanging fruit; it's already using an inline log n algorithm to find a field in most cases, and I bet that's as good as a hash table since n is generally relatively small. But, maybe "in most cases" is wrong; there is a slow-path, and we should confirm that most of the time is in the fast-path code. We could also try a bit of memoization; I wouldn't be surprised if we often lookup "x.y" several times in a row. More often, when I've looked at this kind of thing, though, I've concluded that the problem was that we were calling the routine too often, rather than the routine itself was too slow. Quite possibly we could improve algorithms that are using lookup_field_1 so that they didn't do so as often, by building caches or otherwise. For that, we'd need to look at the callers of lookup_field_1. So, in summary, I'd recommend three things: * Split lookup_field_1 into its fast-path and slow-path code so that we can profile it and figure out which code is taking up most of the time. * Assuming it's fast-path code, look at the frequent callers and think about how to optimize them.
