Merge lp:~mc-return/compiz/compiz.merge-performance-improvements-prevent-unnecessary-operations-if-we-return into lp:compiz/0.9.9
| Status: | Superseded |
|---|---|
| Proposed branch: | lp:~mc-return/compiz/compiz.merge-performance-improvements-prevent-unnecessary-operations-if-we-return |
| Merge into: | lp:compiz/0.9.9 |
| Diff against target: |
1767 lines (+177/-295) 35 files modified
compizconfig/integration/gnome/src/ccs_gnome_integration.c (+1/-2) compizconfig/libcompizconfig/src/compiz.cpp (+18/-26) kde/window-decorator-kde4/window.cpp (+2/-5) plugins/animation/src/grid.cpp (+6/-9) plugins/composite/src/screen.cpp (+2/-2) plugins/composite/src/window.cpp (+4/-6) plugins/cube/src/cube.cpp (+5/-11) plugins/cubeaddon/src/cubeaddon.cpp (+3/-3) plugins/decor/src/decor.cpp (+7/-16) plugins/expo/src/expo.cpp (+1/-2) plugins/firepaint/src/firepaint.cpp (+1/-3) plugins/group/src/selection.cpp (+1/-2) plugins/imgpng/src/imgpng.cpp (+3/-5) plugins/imgsvg/src/imgsvg.cpp (+2/-3) plugins/move/src/move.cpp (+2/-5) plugins/obs/src/obs.cpp (+3/-8) plugins/opengl/src/matrix.cpp (+3/-7) plugins/opengl/src/vector.cpp (+10/-24) plugins/regex/src/regex.cpp (+1/-3) plugins/scale/src/scale.cpp (+11/-16) plugins/scaleaddon/src/scaleaddon.cpp (+1/-2) plugins/shift/src/shift.cpp (+4/-8) plugins/showmouse/src/showmouse.cpp (+1/-3) plugins/switcher/src/switcher.cpp (+2/-2) plugins/trailfocus/src/trailfocus.cpp (+1/-2) plugins/wall/src/wall.cpp (+6/-9) plugins/wobbly/src/wobbly.cpp (+4/-7) plugins/workspacenames/src/workspacenames.cpp (+2/-2) src/action.cpp (+1/-2) src/event.cpp (+3/-8) src/modifierhandler.cpp (+1/-3) src/option.cpp (+1/-3) src/screen.cpp (+14/-32) src/session.cpp (+3/-3) src/window.cpp (+47/-51) |
| To merge this branch: | bzr merge lp:~mc-return/compiz/compiz.merge-performance-improvements-prevent-unnecessary-operations-if-we-return |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | Needs Fixing on 2012-12-05 | |
| Daniel van Vugt | 2012-11-18 | Approve on 2012-12-05 | |
| MC Return | Resubmit on 2012-12-04 | ||
|
Review via email:
|
|||
This proposal has been superseded by a proposal from 2012-12-05.
Commit Message
Minor Performance Optimizations:
* Return ASAP./Prevent executing any unnecessary operations if we return.
* Used De Morgan's laws to merge and simplify if statements.
Other Changes:
* C++ Style: Declared iterator variables inside the for loops they are used in.
* No logic changes have been made.
Description of the Change
I do not claim to have made all optimizations of this kind in this MP here, but for the sake of a reasonable .diff size and easier review I prefer to do the rest of those @ a later stage.
Essentially all the changes here just move bail-out checks to the top, or creation and assignment of variables not needed for the return checks further down the timeline.
Also some if statements have been merged and simplified by using De Morgan's laws.
If you find any logic changes in this MP you have found a mistake, please ping me in this case... :)
| Sam Spilsbury (smspillaz) wrote : | # |
Risk of conflicts later isn't too big a deal IMO, conflicts can be resolved, we shouldn't prevent changes which improve the code on the basis of those.
Just a few general comments:
I note that changing this:
Foo foo;
...
foo = Foo (5);
/* use foo */
to
...
Foo foo (5);
/* use foo */
Is only really effective in C++ because it means that you don't run the default constructor and then the assignment operator. For non plain-old-data types, the compiler cannot optimize out the running of the default constructor at the place the variable is declared because the constructor may change the state of the program.
As for C, it basically means that you can push a new chunk of memory onto the stack and initialize it at the same time, however variable declarations at the top of the block are necessary for C89 compliance (but not C99 compliance) so it will error out if you compile with -pedantic. I don't care which specification we stick to (we are not C89 compliant anyways, and IMO there's no harm in going with C99 as I don't anticipate that we will need to support Windows any time soon), but we should probably make a call and make a note of it somewhere (we really need a coding style document in the source tree)
192 - if (!w)
193 - return;
194 -
195 - if (state == ScaleScreen::Idle || state == ScaleScreen::In)
196 + if (!w || state == ScaleScreen::Idle || state == ScaleScreen::In)
197 return;
It is my opinion that multiple if statements or using temporary booleans are better than compound if statements. We have stuff like this in the unity codebase:
if (!IsWindowMaximized () ||
!IsWindowIn
(!IsWindowH
!AltTabViewable () ||
!SomeOtherThing ())
{
}
And its just a complete mess. Stuff like this:
bool anyVariablesNull = (!w || !foo || !bar);
bool incorrectState = (state == ScaleState::In || state == ScaleState::Out);
if (anyVariablesNull ||
incorrectState)
return;
Is usually a lot better. The compiler can optimize that to be one big condition and return early.
Anyways, I think the best way to fix performance is to use runtime analysis tools to determine hot-spots in the code (like callgrind) in addition to static analysis. Take what static analysis says with a grain of salt - I think the general rule is that for changes like these - if you have a variable declaration that runs a non-trivial constructor, then it is definitely a useful optimization to ensure that constructor is only run once.
Also I'd suggest getting code under test to ensure that the behaviour isn't accidentally changed while refactoring. There's been a bit of that lately from everyone and its causing very subtle but annoying bugs to come up.
| MC Return (mc-return) wrote : | # |
Sam, Daniel - I know of course that the changes presented in this MP only bring minor to not-measurable speed changes. The main thing I tried to achieve here was moving variable declarations and assignments of local variables behind if statements, that would maybe trigger a return and make declaration and assignment of those variables unneeded in the case we return.
All that I did was instead of having:
int a, b, c;
CCSSettingButto
float d, e, f;
int width = serverGeometry.
int height = serverGeometry.
if (something-else)
return
a = 7;
b = 10;
c = 11;
value = ccsSettingGetValue (s)->value.
if (width && height)
We now have:
if (something-else)
return
CCSSettingButto
float d, e, f;
int a = 7;
int b = 10;
int c = 11;
int width = serverGeometry.
int height = serverGeometry.
if (width && height)
So this change:
1. Makes the code more readable, because you instantly know that a, b and c are ints, width and height's declarations and assignment of values are nearer the if statement, where those are actually used.
2. As all of those variables are not needed for the check if we return, we do not need to declare nor to declare and assign values to them, so even if the speed improvement is minor it will be there in the case we return.
The other minor improvements with the merges of if statements I've done here also do not make the code harder to read as maximum 3 ifs have been merged to one -
This is the most complicated one:
if (nDesktop < 1 || nDesktop >= 0xffffffff || nDesktop == this->nDesktop)
I do agree, Sam, that deciphering complicated if statements can get complicated, but not those in this MP ;)
But of course I can also revert those changes if you cannot live with them ;)
So please have a look at the diff again to see that all of the changes are very minor and are all using only those 2 methods of optimization...
| Daniel van Vugt (vanvugt) wrote : | # |
1. This should be simplified:
int i;
for (i = 0; i < nValues; i++)
to:
for (int i = 0; i < nValues; i++)
2. Weird spacing on 496, 504:
495 + int dx = 0;
496 + int width = serverGeometry.
| MC Return (mc-return) wrote : | # |
> 1. This should be simplified:
> int i;
>
> for (i = 0; i < nValues; i++)
> to:
> for (int i = 0; i < nValues; i++)
>
> 2. Weird spacing on 496, 504:
> 495 + int dx = 0;
> 496 + int width = serverGeometry.
I did not do that, because int i is used several times after declaration in several for loops, so I would have to declare it multiple times then - that is why I kept it as it was...
| MC Return (mc-return) wrote : | # |
> 2. Weird spacing on 496, 504:
> 495 + int dx = 0;
> 496 + int width = serverGeometry.
Fixed that. Did not notice that one. Thanks.
| MC Return (mc-return) wrote : | # |
Daniel, 1. and 2. are fixed.
Additional simplifications, type 1., are to be found here:
https:/
| MC Return (mc-return) wrote : | # |
Ping.
| MC Return (mc-return) wrote : | # |
Grmpf, sorry - commits r3519-r3533 should have gone here https:/
Nevertheless everything should work anyway, but I am sorry for making the diff larger than necessary...
| Sam Spilsbury (smspillaz) wrote : | # |
Its possible to get rid of them if you want:
bzr push --overwrite
or just push to a new branch and resubmit this with that as the source.
On Tue, Dec 4, 2012 at 9:57 PM, MC Return <email address hidden> wrote:
> Grmpf, sorry - commits r3519-r3533 should have gone here https:/
>
> Nevertheless everything should work anyway, but I am sorry for making the diff larger than necessary...
>
> --
> https:/
> Your team Compiz Maintainers is subscribed to branch lp:compiz.
--
Sam Spilsbury
| MC Return (mc-return) wrote : | # |
> Its possible to get rid of them if you want:
>
> bzr push --overwrite
>
> or just push to a new branch and resubmit this with that as the source.
>
To be honest, I really hope it is not necessary. Up to r3509 everything
was already checked, up to r3518 I did the fixes Daniel suggested to do.
From r3519 to r3567 I just simplified all of the for iterator declarations
and moved those into their respective for loops. Note that I just did that
for .cpp files to not break C89 compliance (although it is allowed in C99).
The compiler would shout out if one of those variables would be needed outside
their respective for loops and would point out potential human errors made here
immediately.
Also note, that I did not make changes to plugins currently excluded from compilation.
| MC Return (mc-return) wrote : | # |
Ok, now it's ready (I hope) ;)
| Daniel van Vugt (vanvugt) wrote : | # |
Again, changes like this do not actually help with performance.
Please try to focus on fixing bugs in future, if you can.
| Daniel van Vugt (vanvugt) wrote : | # |
Also, in order for a proposal to get noticed after it has been set to Needs Fixing or Resubmit etc, you should click on "Resubmit proposal" to ensure it is more visible in the queue. Otherwise it looks like it still needs fixing from the summary page and won't get any attention.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
| MC Return (mc-return) wrote : | # |
> Also, in order for a proposal to get noticed after it has been set to Needs
> Fixing or Resubmit etc, you should click on "Resubmit proposal" to ensure it
> is more visible in the queue. Otherwise it looks like it still needs fixing
> from the summary page and won't get any attention.
Ok. Here is the first chance to try. :)
(Had to fix a text conflict in shift.cpp)


Changes like these won't actually provide any measurable improvement. At least not in the way they're being used here. They will however increase the risk of conflicts later.
I recommend against merging this. But other people might disagree.