CompRegion::handle()
I think this may be worth inlining privately. As mentioned earlier. We shouldn't make handle() inline for external users of the class. FYI, CompRegion::handle() is consistently the single most called function in compiz, however it never accounts for more than 1.3% of the total CPU usage.
compiz::window::Geometry::border ()
Makes no sense to inline AFAICS. It may well be around the 25th most called function, however it only accounts for 0.07% of the CPU usage.
CompWindow::borderRect()
Does not need to optimizing at all. Is almost never called and contributes absolutely nothing to the total CPU usage.
*Rect()
Contribute almost nothing measurable to the CPU usage.
All-in-all, these optimizations don't seem to provide any significant benefit. I think CompRegion::handle() could be optimized using a private inline version of that function. But even then, the maximum gain is going to be about 1%. The rest of the changes break the ABI, cause a regression, and do not appear to be required at all.
If I'm wrong, then please log a bug with the profile data showing why all this existing code needs optimizing.
CompRegion: :handle( ) :handle( ) is consistently the single most called function in compiz, however it never accounts for more than 1.3% of the total CPU usage.
I think this may be worth inlining privately. As mentioned earlier. We shouldn't make handle() inline for external users of the class. FYI, CompRegion:
compiz: :window: :Geometry: :border ()
Makes no sense to inline AFAICS. It may well be around the 25th most called function, however it only accounts for 0.07% of the CPU usage.
CompWindow: :borderRect( )
Does not need to optimizing at all. Is almost never called and contributes absolutely nothing to the total CPU usage.
*Rect()
Contribute almost nothing measurable to the CPU usage.
All-in-all, these optimizations don't seem to provide any significant benefit. I think CompRegion: :handle( ) could be optimized using a private inline version of that function. But even then, the maximum gain is going to be about 1%. The rest of the changes break the ABI, cause a regression, and do not appear to be required at all.
If I'm wrong, then please log a bug with the profile data showing why all this existing code needs optimizing.