Unused functions impact maintenance
Unused functions in a software project can cause code bloat, but they also create more work for the developers of tests, especially in the situation where code coverage (the quality) of tests is being measured. If a function is not used, then removing it from a project will reduce not only the complexity of the project, but also the amount of tests that need to be written for it. The problem of finding unused functions in software projects is that it can often be time consuming and frustrating.
Coco helps by displaying the function coverage of the execution of the program. In this tip of the week I would like to show you the perks of using Coco's Function Coverage for finding unused functions in your code project.
The example source code
For this presentation I'm using the following C code:
#include <stdio.h>#include <string.h>
int A(char *arg){ printf("A\n"); return !strcmp(arg, "TRUE");}
int B(char *arg){ printf("B\n"); return !strcmp(arg, "TRUE");}
int C(char *arg){ printf("C\n"); return !strcmp(arg, "TRUE");}
int D(char *arg){ printf("D\n"); return !strcmp(arg, "TRUE");}
int main(int argc, char **argv){ if ((A(argv[1]) || B(argv[2])) && (C(argv[3]) || D(argv[4]))) { printf("TRUE\n"); } else { printf("FALSE\n"); } return 0;}
Instrumenting code, and running tests
We will first instrument the code with Coco's Coveragescanner tool. The result is an instrumented executable, and also a .csmes file which contains a database of code lines and their source locations.
$ csgcc -o prog example.c
Next, we run the instrumented program with specific arguments to cause it to execute a code path. This will create an execution report (.csexe file) which contains information about which code was executed. This file will be imported into the generated (.csmes file). As it turns out, with these arguments, the functions B and D are not hit by the test case.
$ ./prog TRUE FALSE TRUE FALSE
We can import the .csexe file into the .csmes file with the following command.
$ cmcsexeimport -m prog.csmes -e prog.csexe -t execution
The final step is to generate the report for the unused functions. Hereby we use the option --function-coverage to specify the coverage level. '--format-unexecuted=' prints the unused functions into the file result.txt by first writing the file( '%f') and then then line ('%l').
$ cmreport --function-coverage -m prog.csmes --format-unexecuted='%f %l' -t result.txt
Listing Unused Functions
The result.txt file contains now:
.../example.c 10
.../example.c 22
If we want to analyze more runs of the program, we can just run the ./prog command with different arguments. The executions will result in additional data concatenated to the .csexe file.
For further information about cmreport and other features of Coco, follow this link.
it is very nice that Qt is considering accelerating for web.
What lacks now is an acceleration for a full multimedia components.
I mean that QGraphicsScene should accept videos as elements (QGraphicsItem).
This way, Qt will advance WPF from Microsoft in these aspects.
But anyway, dealing with videos means dealing with codecs and their respective related patents and copyrights.
This is great.
Do you have any numbers of the improvement?
How does that affect the memory consumption? Does a transformation on big layer (let's say the <body> tag) involve caching a pixmap of the complete layer in memory?</body>
Benjamin:
The numbers for improvement would change per animation. Like I said, for the leaves demo I see the FPS improving by x4 on raster engine.
Re. memory consumption - this is all QGraphicsView cache, which relies on QPixmapCache, which can be tweaked by QPixmapCache::setCacheLimit(...). btw this is true not just for Webkit, but also for graphics-view based UIs that involve complex elements that have to be animated: The QPixmapCache::setCacheLimit(...) function would tweak the balance between RAM usage and paint performance. But yes, without caching that big layer as a pixmap - paint performance degrades because webkit has to re-render it for each frame.
Note that the leaves demo is rather unusual: the animation is running continuously. The normal use-case for CSS animations is animated transitions between states, which would clean up the layer and thus the image cache after it's done.
Some more numbers using n900 with raster engine: (FPS without accel -> FPS with accel, higher is better)
Translate animation on an HTML table: 10 -> 60
Rotate animation on an element with border-shadow: 7 -> 14
Opacity animation on inline text: 2 -> 18
Scale animation on a medium-size transparent image: 17 -> 24
Scale animation on a large image: 11 -> 18
So acceleration has the potential to give us x2 acceleration for rotation of painted elements, x1.5 for images, x6 for simple HTML elements and x10 for inline text.
Looking good, though I had trouble building the head revision..?
../../../WebCore/platform/graphics/qt/GraphicsLayerQt.cpp:690: error: explicit template specialization cannot have a storage class
../../../WebCore/platform/graphics/qt/GraphicsLayerQt.cpp:700: error: explicit template specialization cannot have a storage class
Sounds interesting project. Can you share a video of that demo running on N900?
@zchydem: to your request, I uploaded a short video:
http://labs.qt.nokia.com/bl...
This runs at about 9 FPS, compared to 2 FPS without compositing. (still not enough, of course).
@Nick: please try again, I think my new commit should fix it. If it doesn't, please let me know which platform/environment you use so I can try to reproduce the problem...
No'am: That commit did the trick =)
The 9FPS on the N900 is not surprising. The CPU usage for that leaves demo is quite high - on this modern Quad Core desktop computer.
The best result I saw was with -graphics-system opengl, and even that seemed too high to expect smooth playback on a small device.
Still, a very good step up. Excellent work =)
@Nick: the leaves fall rather smoothly on the iphone that I'm posting from =)
@No'am
You should try the demo without compositing with the Qt-maemo branch, usually that doubles the FPS.
@aidan
Don't forget the iPhones have a low-resolution screen (153600 pixels against 384000 for a N900).
Great work. Could these changes work in WinCE devices?