On Dienstag, 12. Juli 2016 14:23:13 CEST Josef Weidendorfer wrote: > Am 08.07.2016 um 01:03 schrieb Stepan Zakharov: > > Hello, > > If I remember correct, callgrind takes x30 overhead in general (when I > > was running it). Usually , I had to run it on small tasks that won't > > take more then a few minutes, so this was not a bother to me. > > > > But right now I am wonering if I can measure the entire life-span of > > critical stages in our application. Usually, it takes up to 20 hours to > > perform a load test. And I would like to measure that period. For > > callgrind it means to run 20x30=600hrs. Which is 25 days. Is it really > > possible to run and record for such a long time? I heard the Counters in > > CallGrind are 64-bit so this part should not be the problem, but what > > I'm worrying about is the RAM overhead. > > Callgrind allocates a bunch of 64-bit counters for every instruction > in the binary which gets executed at least once, as well as counters > for jump/call arcs happening among blocks of instructions in your code. > Both is bound by the codes size/algorithms executed, but it does not > matter if code/jumps are executed only once or multiple times. > > That is, if all code paths of your program get already executed in the > first few minutes, the memory requirement of callgrind should not increase > afterwards. > > > It will kinda need to store all > > the upcoming dump in memory, isn't it? How much big will it be? And if > > so, will the CallgrindAnnotate or graphical tool (forgot the name) > > accept to proccess such a big dump? > > Same applies here: there should be no problem. > > > So, basically, these are my questions. Will be very grateful if you > > could enhance my knowledge about the capabilities of the tool. > > Perhaps interesting for you is the "fast-forward" mode of callgrind which > allows to dynamically switching on/off profiling to skip program phases > with the benefit of reducing the slow-down to around 2x (same as > Valgrind's "none" tool)
While this is much faster, you have to be aware that Valgrind will still serialize your code. So if you are running N threads in parallel, you get an additional overhead of Nx on top of the 2x. Depending on what you are trying to achive, I suggest looking into a sampling profiler like perf. If you let it run for a really long time, the data file will be enormous, so I suggest you do some kind of live analysis (perf top). Bye -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
