runtests: enable torture testing with threaded resolver - #19786
Conversation
a9d3859 to
89acdb3
Compare
Since a7bebd8 made it possible. Also enable memdebug in test 3207 again.
it still does not work properly for some reason
89acdb3 to
3b35c62
Compare
|
Analysis of PR #19786 at 89acdb36: Test ../../tests/http/test_16_info.py::TestInfo::test_16_03_info_upload[h2] failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 2 different CI jobs (the link just goes to one of them). Generated by Testclutch |
|
It seems that Windows arm64 tests became much slower First seen in this PR, and in almost all runs since: It also applies to Intel builds, but those took 3 minutes and Reference from before: master build after: (affects both MSVC and mingw. there is bottleneck somewhere |
|
windows arm64 MSVC time summaries: Before: After: |
…t run) Patch #19786 removed an exception, which caused many more CI jobs to run `memanalyze.pl`. It resulted in a 10-30% (Linux), 15% (macOS), 100% (2x, on Windows) slowdown of runtest steps. It also made some jobs exceed their time limits and fail (seen with the Windows ARM64 job.) Turns out the overhead was caused by calling `memanalyze.pl` as an external process (twice per test), which in turn had to load a full Perl stack from scratch each time. Fix by converting memanalyze to a Perl modul, loaded as part of `runtests.pl`, which eliminated the overhead completely. It also sped up existing jobs where memanalyze was run for a long time, e.g. two c-ares Windows jobs, saving 4.5m per CI run. Supersedes #19819 Bug: #19786 (comment) Follow-up to fb7033d #19786 Closes #19821
Since a7bebd8 made it possible.
Also enable memdebug in test 3207 again.