|
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? -- |