[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Need help profiling kreversi
From:       Benoit Jacob <jacob.benoit.1 () gmail ! com>
Date:       2011-08-04 6:08:17
Message-ID: CAJTmd9rukJJeKhAaQGWD2=WW+XQBkMYhK9vdfZGqr5Gqag1kOg () mail ! gmail ! com
[Download RAW message or body]

Profiling is a solved problem on recent linux versions, thanks to the
new 'perf' profiler.

Depending on your distro it could be provided by a package named
'linux-tools' or some such.

It improved a lot in recent versions but as of linux 2.6.38 it's
state-of-the-art.

To use it:
1. start kreversi, note its pid (use ps aux | grep kreversi)
2. open a terminal
3. when you want to start profiling (e.g. while the computer is thinking) do:

    $ perf record -f -g -p 12345

(replace 12345 by the PID of kreversi)

4. when you want to end the profiling, kill perf by hitting Ctrl+C
5. to view the results, do:

   $ perf report

You shouldn't need special build options, except perhaps "no omit
frame pointers" on x86-64. Of course you need to have symbols for the
output to be useful, so make sure your executable isn't stripped.

Callgrind is only a CPU simulator, not a hardware profiler. So it's
not as reliable as something that relies on actual performance
counters. That's also why it runs slow.

Benoit

2011/7/31 Andreas Beckermann <b_mann@gmx.de>:
> Hello Dominik,
>
> I don't use oprofile, so I'm afraid I can't help you with that. For the KDE
> build process, have you taken a look at
>  http://techbase.kde.org/Development/CMake/Addons_for_KDE
> ("Buildtypes" seems relevant to you)?
>
> However I'd like to suggest an alternative: Have you tried valgrind/callgrind
> already?
>  valgrind --tool=callgrind kreversi
> -> this runs kreversi in callgrind. No recompilation of the application is
> required.
> Callgrind emulates a CPU, so it will run a *lot* slower, but the profiling
> information is (for CPU profiling) usually very dependable and reproducible.
> Once you close the application, a file callgrind.out.<pid> is written to the
> current directory which can be opened by kcachegrind and gives you a
> callgraph. You can play around with the settings there ("Relative" and
> "Relative to Parent" are usually helpful, both on and off).
>
> Note that callgrind is not suited for profiling stuff that runs on the graphic
> cards (most OpenGL calls).
>
> Greetings
> Andi
>
> On Sunday 31 July 2011, Dominik Raddatz wrote:
>> Hi Everyone,
>>
>> on my netbook kreversi plays too slow. To see where it spends too much time
>> I want to profile it with gprof.
>> Oprofile does work, but it doesn't tell me whether functions are called too
>> often or are running too slow.
>>
>> Therefore I need to specify -pg to the compiler.
>>
>> Where do I have to do that using the "default cmakekde"-script?
>> There is a local CMakeCache.txt, but it doesn't seem to be used.
>>
>> Where can I see which compiler options were actually being used for which
>> file?
>>
>> How do I invoke targets other than default (like debug or profile) as
>> mentioned in the documentation?
>>
>> Is there documentation describing in more detail how the KDE build process
>> works and which files are accessed in which order?
>>
>> Thanks
>> Dominik
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]