Hi,

this is my first post in this mailing list ever, I am developer of few C-based plugins for gimp, but overall I am not professional developer. Now I have a question about profiling of plugins.

I have some experiences with debugging a plugin with valgrind, but now I would like to get an output like provided by gprof. The purpose is to try to speed up a plugin. So I need to identify and measure top functions by their CPU time usage.

I tried to google but almost to no avail. So what tool should be best for it? Is it possible to make gprof work with gimp plugin - this tools seems to be very easy to use, so I would be fine with it.

Thanks

PS: this is not a question but right now I found that if I compile plugin with limit 1 thread only and then with limit 2 threads, the CPU time goes up by about 42 %. Of course real time (that is important from user's perspective) goes down by 10%, but it is ONLY 10 %. So this behaviour is another reason why I would like to know what is going on during processing...

Hi,

I reply to my own post. On the second time using gprof turned to be easy. In case anybody is interested, the steps are:

1. you need the gimp compiled with debug option [but this I am not sure about, and can not test right now]
2. Compile your plugin with '-pg' switch. If you are using gimptool-2.0 command to compile, just copy&paste that long command it prints out and put '-pg' just after gcc, like:
gcc -pg -pthread -I/usr/include/gimp-2.0 -I/usr/include/gtk-2.0 ..............
3. run gimp from command line (stop other instances beforehand) and work a bit with your plugin you are to profile, and quit it. (You might quit gimp here as well)
4. in the directory where you run the gimp from, you can find file 'gmon.out' and thus run following:

gprof ~/.gimp-2.8/plug-ins/colorblur

(yes the actual path to plugin binary is needed, also piping to a file or to 'more' command might be suitable)

The output would look like:

Flat profile:

Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 97.62 0.41 0.41 blur_step 2.38 0.42 0.01 1 10.00 10.00 fill_tmp 0.00 0.42 0.00 378043 0.00 0.00 basepos 0.00 0.42 0.00 40000 0.00 0.00 get_bright [and more lines and sections to follow]

Here in my example I found what I expected (First column is interesting to me). And in fact the result is not that usefull for me...

So maybe this small howto will be usefull for somebody...

Regards

2013/3/8 Tibor Bamhor

Hi,

this is my first post in this mailing list ever, I am developer of few C-based plugins for gimp, but overall I am not professional developer. Now I have a question about profiling of plugins.

I have some experiences with debugging a plugin with valgrind, but now I would like to get an output like provided by gprof. The purpose is to try to speed up a plugin. So I need to identify and measure top functions by their CPU time usage.

I tried to google but almost to no avail. So what tool should be best for it? Is it possible to make gprof work with gimp plugin - this tools seems to be very easy to use, so I would be fine with it.

Thanks

PS: this is not a question but right now I found that if I compile plugin with limit 1 thread only and then with limit 2 threads, the CPU time goes up by about 42 %. Of course real time (that is important from user's perspective) goes down by 10%, but it is ONLY 10 %. So this behaviour is another reason why I would like to know what is going on during processing...

Hi,

Thank for you interest. Today I spent some time reading about perf - it is quite complex tool or rather it measures things that I am not familiar with. However I did some primitive testing and got this output:

____7729.437618_task-clock________________#____0.386_CPUs_utilized__________ ___________8556_context-switches__________#____0.001_M/sec__________________ ______________0_cpu-migrations____________#____0.000_K/sec__________________ ____________899_page-faults_______________#____0.116_K/sec__________________ ____20346686795_cycles____________________#____2.632_GHz_____________________[92.65%] ______________0_stalled-cycles-frontend___#____0.00%_frontend_cycles_idle____[99.92%] ______588881284_stalled-cycles-backend____#____2.89%_backend__cycles_idle____[67.69%] _____2234245557_instructions______________#____0.11__insns_per_cycle________ __________________________________________#____0.26__stalled_cycles_per_insn_[71.21%] ______931561726_branches__________________#__120.521_M/sec___________________[77.62%] _____1877007958_branch-misses_____________#__201.49%_of_all_branches_________[84.88%]

I dont dare to interpret it, but the "201.49%" in last line was in red so there is obviously a problem there. Here I would start.

If you (or anybody else) can point me at some source on internet I would be thankfull. Or perhaps shortly explain how to mitigate the problem. But I understand this is not gimp-specific issue...

BTW, I consider my question answered now, thanks :)

Tibor

2013/3/10 Ville Sokk

I'm sorry you didn't get any help. But I would like to note that gprof is generally not considered a good tool for profiling, especially if threads are involved. People suggest statistical profilers like perf (Linux kernel profiler, works in userspace too), gperftools, oprofile, dtrace (not just a profiler). If you have a mac you can use its GUI for dtrace. If you are adventurous you can use the Linux equivalents of dtrace called systemtap and LTTng. Jon Nordby likes gperftools IIRC, you can analyse its output with kcachegrind. For perf you can use gprof2dot to get a graphical callgraph instead of the CLI one.

Well, I have a lot of if/then in code, but they are essential. So probably no opportunity here.

I will look on the links you provided anyway, thanks...

2013/3/11 Jon Nordby

Yes, if you have branches in inner loops eliminating them can give large speedups.
A quick google search gave this reference which looks like an OK start:

http://software.intel.com/en-us/articles/avoiding-the-cost-of-branch-misprediction Less branching may also allow the compiler to auto-vectorize more. If you are unable to remove the branches in your inner loop, you can try to guide the branch predictor using GCCs __builtin_expect:
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Note that not just if/case statements introduce branching, do/while/for do as well.

--
Jon Nordby - www.jonnor.com