|
From: flowher <krz...@le...> - 2012-03-01 14:24:28
|
Hello, I'm having an issue with valgrind - mine regression takes 4 hours instead of 45 mins when run in valgrind. I would like to keep my set of regression tests untouched as they are quite complicated. Another idea is to try to speed up valgrind's memcheck, so will memcheck speed up if I: 1. reduce number of memory leaks (our product is quite new and right now we have around 50k records per build) 2. remove/add some options - right now we have set below, might be that we need only those which are critical and we can leave with the rest. so will valgrind speed up f.e. by removing show-reachable or any others which are kind of "heavy" --tool=memcheck --xml=yes --log-fd=-1 --xml-file=$OUTFILE --demangle=no --error-limit=no --leak-check=full --undef-value-errors=no --show-reachable=yes --suppressions=$SUPDIR/valgrind_leak_suppressions.sup --time-stamp=yes --read-var-info=yes" 3. substitute valgrind with any other tool (for linux), in this case what else is worth checking ? All ideas welcome :) Kris |
|
From: John R. <jr...@bi...> - 2012-03-01 15:09:26
|
> I'm having an issue with valgrind - mine regression takes 4 hours instead > of 45 mins when run in valgrind. An elapsed time ratio of 240:45 (5.3 : 1) is not unusual, and may be better than average. > I would like to keep my set of regression > tests untouched as they are quite complicated. > Another idea is to try to speed up valgrind's memcheck, so will memcheck > speed up if I: > 1. reduce number of memory leaks (our product is quite new and right now > we have around 50k records per build) The wall-clock cost (inside memcheck) of a leak is nearly all upon exit(). So watch a run, and see how much time is spent before and after exit(). [Of course, too many leaks tends to make the program's allocator slow (and also reduces the efficiency of hardware caches) independent of memcheck.] > 2. remove/add some options - right now we have set below, might be that we > need only those which are critical and we can leave with the rest. so will > valgrind speed up f.e. by removing show-reachable or any others which are > kind of "heavy" > --tool=memcheck --xml=yes --log-fd=-1 --xml-file=$OUTFILE --demangle=no > --error-limit=no --leak-check=full --undef-value-errors=no > --show-reachable=yes --suppressions=$SUPDIR/valgrind_leak_suppressions.sup > --time-stamp=yes --read-var-info=yes" --read-var-info can be expensive; try removing it. Consulting suppressions is expensive; reduce complaints as much as possible. > 3. substitute valgrind with any other tool (for linux), in this case what > else is worth checking ? The fastest valgrind could ever run is with --tool=none. How far away from that is --tool=memcheck? -- |
|
From: Dallman, J. <joh...@si...> - 2012-03-01 15:36:17
|
John Reiser [mailto:jr...@bi...] wrote: > > I'm having an issue with valgrind - mine regression takes 4 hours instead > > of 45 mins when run in valgrind. > An elapsed time ratio of 240:45 (5.3 : 1) is not unusual, and may be better > than average. That's definitely better than I see: I'm usually in the 20:1 to 30:1 range. -- John Dallman |
|
From: Brian B. <bri...@gm...> - 2012-03-01 17:01:43
|
On Thu, Mar 1, 2012 at 7:23 AM, Dallman, John <joh...@si...> wrote: > John Reiser [mailto:jr...@bi...] wrote: > >> > I'm having an issue with valgrind - mine regression takes 4 hours instead >> > of 45 mins when run in valgrind. >> An elapsed time ratio of 240:45 (5.3 : 1) is not unusual, and may be better >> than average. > > That's definitely better than I see: I'm usually in the 20:1 to 30:1 range. > > -- > John Dallman Indeed mine is hundreds to one since our application is heavily multithreaded. Count your blessings ;) Brian |