Regression in build times for Travis CI using 2.2.300 SDK

From @martincostello on Saturday, June 8, 2019 9:32:34 AM

I’ve noticed across several different projects I maintain that since the SDK was updated from 2.2.1xx or 2.2.2xx to 2.2.300, the time to build the projects in Travis CI has regressed by up to an order of magnitude on both Linux and macOS.

However I’m not seeing the same regression in Azure DevOps pipelines for Linux, macOS or Windows, or AppVeyor for Windows.

Below are a selection of projects that show a build time regression immediately after merging a PR that contains a commit that updates the SDK to 2.2.300:

History	Build time pre-update	Build time post-update	Delta	PR with SDK update	Commit with SDK update
project-euler	3 min 40 sec	37 min 13 sec	+1,015%	#33	b2c7ed3
JustEat.StatsD	2 min 33 sec	12 min 19 sec	+483%	#177	4f4ac55
sqllocaldb	3 min 31 sec	16 min 28 sec	+468%	#88	671307a
adventofcode	7 min 4 sec	31 min 51 sec	+450%	#72	8ecc3a7
JustSaying	6 min 49 sec	25 min 55 sec	+380%	#545	88f241c
httpclient-interception	6 min 26 sec	16 min 26 sec	+255%	#85	065c722
alexa-london-travel-site	5 min 34 sec	11 min 31 sec	+206%	#267	48b47a5
api	5 min 54 sec	9 min 46 sec	+165%	#112	40c1dee
website	4 min 26 sec	7 min 13 sec	+162%	#263	3a43580

My hunch is that it is related to the new “progress bar” when running dotnet test which is causing the Travis agents to waste a lot of time trying to “draw” it because the actual test run times printed in the build output are equivalent:

• Build before - Time Elapsed 00:00:10.86
• Build after - Time Elapsed 00:00:15.31
• Test before - Test execution time: 46.8778 Seconds
• Test after - Total time: 46.5308 Seconds

Copied from original issue: dotnet/sdk#3314

[mayankbansal018]

this should be fixed via https://github.com/dotnet/cli/pull/11497, will keep it open for tracking

[martincostello]

I’m also still observing this with the 3.0.100-preview8-013656 SDK - has the fix been ported to the 3.0.0 SDK yet?