Comment by rwmj 6 months ago This is why you should have an option (enabled routinely in your CI) to run your tests under valgrind. 3 comments rwmj Reply throw-qqqqq 6 months ago I do this too, but valgrind is slow! In my experience, the runtime increases a factor of 10/20/30x .. rwmj 6 months ago Yes, it's definitely slow. That's why we have an option to run the same tests normally or with valgrind, and mainly use valgrind runs in our CI system after changes have been committed. thefaux 6 months ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
throw-qqqqq 6 months ago I do this too, but valgrind is slow! In my experience, the runtime increases a factor of 10/20/30x .. rwmj 6 months ago Yes, it's definitely slow. That's why we have an option to run the same tests normally or with valgrind, and mainly use valgrind runs in our CI system after changes have been committed. thefaux 6 months ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
rwmj 6 months ago Yes, it's definitely slow. That's why we have an option to run the same tests normally or with valgrind, and mainly use valgrind runs in our CI system after changes have been committed. thefaux 6 months ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
thefaux 6 months ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
I do this too, but valgrind is slow! In my experience, the runtime increases a factor of 10/20/30x ..
Yes, it's definitely slow. That's why we have an option to run the same tests normally or with valgrind, and mainly use valgrind runs in our CI system after changes have been committed.
I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.