← Back to context Comment by rwmj 4 days 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 4 days ago I do this too, but valgrind is slow! In my experience, the runtime increases a factor of 10/20/30x .. rwmj 4 days 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 4 days ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
throw-qqqqq 4 days ago I do this too, but valgrind is slow! In my experience, the runtime increases a factor of 10/20/30x .. rwmj 4 days 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 4 days ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
rwmj 4 days 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 4 days ago I can't help but notice the subtle ways in which git has corrupted our understanding of the word commit.
thefaux 4 days 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.