单元测试需要很长时间才能运行。瓦尔格林德问题？冠状病毒问题？
我已经为我正在从事的项目创建了一个单元测试套件。我的单元测试过去运行得非常快……其中 200 多个单元测试将在几秒钟内运行。通常每个测试花费的时间不到 10 毫秒。现在，使用 Valgrind 和 Gcov 时，每个测试的运行时间可能超过 1.5 分钟！有没有人有过非常慢的单元测试的经验？ Valgrind、gcov 或 Google Test 在任何特定情况下是否会导致程序执行速度显着减慢？更令人困惑的是，一些单元测试运行得很好（即非常快），而另一些则需要很多秒才能运行。通常，当再次运行单元测试时，相同的测试需要不同的时间来运行。我基本上是想找出瓶颈在哪里。下面是一个例子：
[ RUN ] BandwidthAlgorithmTest.TerminalsOnly
[ OK ] BandwidthAlgorithmTest.TerminalsOnly (34 ms)
[ RUN ] BandwidthAlgorithmTest.AlohaAndTerminals
[ OK ] BandwidthAlgorithmTest.AlohaAndTerminals (38 ms)
[ RUN ] BandwidthAlgorithmTest.AllocatePeriodic
[ OK ] BandwidthAlgorithmTest.AllocatePeriodic (304 ms)
[ RUN ] BandwidthAlgorithmTest.AllocatePeriodic_Disabled
[ OK ] BandwidthAlgorithmTest.AllocatePeriodic_Disabled (152 ms)
[ RUN ] BandwidthAlgorithmTest.AllocateFair
[ OK ] BandwidthAlgorithmTest.AllocateFair (109 ms)
[ RUN ] BandwidthAlgorithmTest.AllocateFair_Disabled
[ OK ] BandwidthAlgorithmTest.AllocateFair_Disabled (64 ms)
[----------] 12 tests from BandwidthAlgorithmTest (2763 ms total)
[----------] 7 tests from BacklogHelperTest
[ RUN ] BacklogHelperTest.ChangeInrouteState
[ OK ] BacklogHelperTest.ChangeInrouteState (80613 ms)
[ RUN ] BacklogHelperTest.GetInvalidInroute
[ OK ] BacklogHelperTest.GetInvalidInroute (98471 ms)
I've created a unit test suite for a project I'm working on. My unit tests used to run very quickly... 200+ of them would run within a few seconds. Typically each test would take less than 10 milliseconds. Now while using Valgrind and Gcov each test can take over 1.5 minutes to run! Has anyone had any experience with very slow unit tests? Does Valgrind, gcov, or Google Test cause significant slowdown of program execution in any particular situations? What's even more confusing is that some of the unit test run just fine (i.e. very quickly) while others take many seconds to run. And often, when running the unit tests again, the same tests take a different amount of time to run. I'm basically trying to figure out where the bottleneck is. Below is an example:
[ RUN ] BandwidthAlgorithmTest.TerminalsOnly
[ OK ] BandwidthAlgorithmTest.TerminalsOnly (34 ms)
[ RUN ] BandwidthAlgorithmTest.AlohaAndTerminals
[ OK ] BandwidthAlgorithmTest.AlohaAndTerminals (38 ms)
[ RUN ] BandwidthAlgorithmTest.AllocatePeriodic
[ OK ] BandwidthAlgorithmTest.AllocatePeriodic (304 ms)
[ RUN ] BandwidthAlgorithmTest.AllocatePeriodic_Disabled
[ OK ] BandwidthAlgorithmTest.AllocatePeriodic_Disabled (152 ms)
[ RUN ] BandwidthAlgorithmTest.AllocateFair
[ OK ] BandwidthAlgorithmTest.AllocateFair (109 ms)
[ RUN ] BandwidthAlgorithmTest.AllocateFair_Disabled
[ OK ] BandwidthAlgorithmTest.AllocateFair_Disabled (64 ms)
[----------] 12 tests from BandwidthAlgorithmTest (2763 ms total)
[----------] 7 tests from BacklogHelperTest
[ RUN ] BacklogHelperTest.ChangeInrouteState
[ OK ] BacklogHelperTest.ChangeInrouteState (80613 ms)
[ RUN ] BacklogHelperTest.GetInvalidInroute
[ OK ] BacklogHelperTest.GetInvalidInroute (98471 ms)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您对 valgrind 的性能感到失望，您可以尝试来自 Google 的刚刚起步的 AddressSanitizer。 http://blog.chromium.org/2011/06/testing -chromium-addresssanitizer-fast.html 它需要使用特殊的编译器重新编译代码，但不需要进行源代码级别的更改。
If you're disappointed by valgrind's performance, you can try the fledgling AddressSanitizer from Google. http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html It requires recompiling your code with a special compiler, but no source-level changes are needed.
这里提到了一个潜在的原因：https://groups.google。 com/forum/#!topic/gnu.gcc.help/aS3mQGzGE_4 - 似乎 gcov 在某处有一个 O(n^2) 步骤并且对 long 敏感（后 CPP）源代码行，或类似的内容。
One potential reason is mentioned here: https://groups.google.com/forum/#!topic/gnu.gcc.help/aS3mQGzGE_4 - it seems gcov has an O(n^2) step somewhere and is sensitive to long (post-CPP) source lines, or something along these lines.