Speed up VS2017 Appveyor which is taking 45 mins #4059
Assignees
Comments
This was referenced Jan 27, 2020
|
The longest-running test by far is nudge_test: 10 minutes! I took a look and found a lot of issues: #4074: ASSERT in ntdll_redir in infloop on nudge => relax for nudge thread; actually I undid this after the next assert was fixed to not swap stateI fixed this. #4074: ASSERT in infloop in tls cleanup post-nudge => swapping peb pointer too earlyI fixed this. #4075: deadlock in infloop when nudge sent: thread_initexit_lock has no owner but lock_requests==4I failed to figure this one out. But at least with the changes below we now exit in a reasonable time. Add timeouts to all wait loops in runall.cmakeNow we have: I also added a TIMEOUT to the execute_process() call. Add detection of assert to runall.cmake |
|
New breakdown showing 32-bit shrunk down a bit now, 10 mins instead of 15: Next target: the 4 drcachesim tests running the client.annotation-concurrency test, each taking 50-100 seconds in each of 32-bit and 64-bit. The plan is to parametrize the matrix size and iterations. |
derekbruening
added a commit
that referenced
this issue
Feb 2, 2020
Parametrizes the client.annotation-concurrency test to optionally take in the matrix size and iteration count. Changes the 4 drcachesim tests that use this application to pass in a 128 size and 5 iterations, instead of the default 512 and 10, shrinking their execution time by 7x. Issue: #4059
derekbruening
added a commit
that referenced
this issue
Feb 2, 2020
Parametrizes the client.annotation-concurrency test to optionally take in the matrix size and iteration count. Changes the 4 drcachesim tests that use this application to pass in a 128 size and 5 iterations, instead of the default 512 and 10, shrinking their execution time by 7x. Issue: #4059
|
I'm thinking of disabling test building for the 64-bit release build for PR's, since we're not running the tests there (only doing release tests for Linux). That should save at least 5 minutes (!). Another option would be to reduce the # of tests run for 32-bit. This assumes that 32-bit Windows is not as important these days. I would remove some of the less differentiated tests, like half the drcachesim ones. We would still leave the full set for the merge to master. |
derekbruening
added a commit
that referenced
this issue
Feb 2, 2020
For Appveyor PR's (master merges remain unchanged): + Disables building tests for the 64-bit release build, since we're not running those (only running on Linux). + Disables less-differentiated tests for 32-bit: removes most from each group of tool.drcachesim, tool.drcpusim, tool.[^d], client.annotation-*. Issue: #4059
|
Down to 29:23 now. Latest breakdown: |
derekbruening
added a commit
that referenced
this issue
Feb 3, 2020
…4079) For Appveyor PR's (master merges remain unchanged): + Disables building tests for the 64-bit release build, since we're not running those (only running on Linux). + Disables less-differentiated tests for 32-bit: removes most from each group of tool.drcachesim, tool.drcpusim, tool.[^d], client.annotation-*. Issue: #4059
derekbruening
added a commit
that referenced
this issue
Feb 9, 2020
Switches to a separate invocation of package.cmake for cronbuilds, to make them look like release packages. Cronbuilds on Travis and Appveyor no longer run the same jobs as a regular build but instead run one package.cmake job. Checks out Dr. Memory to include it in the package. Does a shallow clone, assuming 250 is enough for the embedded DR. Excludes drmemory/ from vera checks. Removes the "package" parameter from non-cron builds which should make them a little faster (xref i#4059). There are still further decisions and actions but now the cronbuilds have the same content as past manual builds. Issue: #2861, #4059
|
I removed the fig2dev, ghostscript, and imagemagick installs for #3235. After: So that shrunk install time from 1:37 to 0:45. |
|
So today we're looking at PR builds taking ~27.5 mins, and master builds ~35.5 mins. Breakdowns: So 5 mins for each of the main builds, 5 mins for -32 tests, 7 mins for -64 tests, 5 mins for the final 2 builds. Master has +3 mins on -32 tests (has the tests I removed from the PR's); +2 mins on rel-64 build (building tests while PR is not); +3 mins building vps: At this point further gains for PR's could come from:
For master:
For shortening long tests here are the longest ones: I don't think samples_proj is going to get faster: so we're talking about speeding up the drcachesim tests further. Cutting, say, 10 of those 15s-30s in half would save say 4 mins cpu time, but with parallel jobs might save 1-2 mins overall? |
derekbruening
added a commit
that referenced
this issue
Feb 22, 2020
Removes the 32-bit release build from PR builds (the 64-bit should catch nearly all warnings). Further shrinks drcachesim tests using the Jacobi app by dropping to a 64 matrix size and 3 instead of 5 iterations. Shrinks drcacheoff tests on Windows by capping the trace sizes at 1M, except for basic_counts which needs the full run to see kernel events. Relaxes all of the templates to allow for correspondingly varying simulator statistics. Issue: #4059
derekbruening
added a commit
that referenced
this issue
Feb 22, 2020
Removes the 32-bit release build from PR builds (the 64-bit should catch nearly all warnings). Further shrinks drcachesim tests using the Jacobi app by dropping to a 64 matrix size and 3 instead of 5 iterations. Shrinks drcacheoff tests on Windows by capping the trace sizes at 1M, except for basic_counts which needs the full run to see kernel events. Relaxes all of the templates to allow for correspondingly varying simulator statistics. Issue: #4059
|
Now we're down to 23:20: There are only 4 tests over 20s now. Going to call this good enough. |
This was referenced Apr 12, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
VS2013 was taking ~33 mins.
Some of this may be some timeouts. Some may be a slower compiler?
Build and test times:
We can probably shrink some of the longer tests: like drcachesim tests running that concurrency
app and taking a minute each.
The text was updated successfully, but these errors were encountered: