On Mon, Feb 12, 2007 at 12:55:00PM +0000, Andrew Haley wrote: > This is one of the penalties of early inlining. I suppose we could > attempt to inline again at the end of optimization, and maybe this > would reveal a few opportunities we'd missed, but in most cases it > wouldn't be worthwhile. > > Andrew. In general I'd agree with this as well. But for applications using callbacks in this way as a way of using light-OO + their own namespace, I think it would definitely be a benefit in that the overhead of function calling was taken out of the picture. I can think of atleast one major library which could see benefit: berkeley db. It uses these constructs for nearly everything (e.g. data = db->get(db, NULL, key, 0)). Of course there is no guarantee that db_get (or whatever their internal call is named) wouldn't overstep the inlining limits, but if it didn't, a simple loop processing each return from db_get would benefit from something like this, I would think. The question is how to implement it in such a way that doesn't take a lot of work or hassle. -finline-post-optimize? :P -cl
