Simplify innerloop build?

[saucecontrol]

I was just having a look at the JPEG codec to see if there's any low hanging fruit optimization-wise, but I'm having a few issues due to the way the project is set up. Project builds fine with dotnet cmdline, but VS is giving me fits, starting with an error from MinVer just saying a command failed.

I believe I've tracked that one down to not having git in my system default path, which I prefer not to do for security reasons. I do put it on the path in my dev command prompt, which I think is why cmdline build works.

The build time is also quite long in no small part due to the manymany TFMs.

I wonder if you might consider adding another config (I call it Dist in my projects) that does the things only needed for a true "Release" build, like running MinVer. I use the Release config as more of a "Checked" build, with optimizations and all that but with extra checks on buffer bounds and the like, and that config targets only the TFMs I actually run tests against (i.e. you can't actually run on NETStandard). @JimBobSquarePants @antonfirsov would you be open to something like that?

[JimBobSquarePants]

The MinVer issue has been on my mind recently actually having seen that same issue. I can disable that when we're not on CI in our infrastructure solution and use the fix in all our solutions.

I think reducing the TFM count would be good also for rapid dev. Build time are brutal at the moment and anything to reduce that is welcome.

[saucecontrol]

Nice! I guess skipping SourceLink outside CI would knock a few cycles off as well.

I've seen some projects that use MSBuild properties to control things like that, but I like the all-in-one nature of an alternate configuration, and adding it to the <Configurations> property makes it show up in VS so contributors can see it and verify they're not breaking something in one of the TFMs not built in the innerloop configs.

[antonfirsov]

+1 for making MinVer to run only on CI.

The build time is also quite long in no small part due to the manymany TFMs.
[...] and that config targets only the TFMs I actually run tests against (i.e. you can't actually run on NETStandard)

With our amount of TFM-s, removing only the NETStandard-s doesn't help much, for an efficient dev innerloop builds need to be as fast as possible. Any time I open pull down the code and open the solution, I start by wiping out everything except netcoreapp3.1, since it's not that frequent, that we actually work on add target-dependent code. I was thinking for a long time about automating this by adding configurations Debug-InnerLoop and Release-InnerLoop which do something like:

<PropertyGroup Condition=" $(Configuration.EndsWith('InnerLoop')) == true ">
    <TargetFrameworks>netcoreapp3.1</TargetFrameworks>
</PropertyGroup>
<PropertyGroup  Condition=" $(Configuration.EndsWith('InnerLoop')) == false ">
    <TargetFrameworks>netcoreapp3.1;netcoreapp2.1;netstandard2.1;netstandard2.0;netstandard1.3;net472</TargetFrameworks>
</PropertyGroup>

---

I was just having a look at the JPEG codec to see if there's any low hanging fruit optimization-wise

Before you rediscover it, I recently identified #1597 which is probably our biggest Jpeg issue, though it's rather a mid-size refactor rather than a low hanging fruit.

[saucecontrol]

Before you rediscover it, I recently identified #1597 which is probably our biggest Jpeg issue

I saw that one, but yeah, I'm just dipping my toes in, so I won't be able to do that kind of refactoring for a while. Was just looking at HuffmanScanDecoder since that shows up as being around 45% of CPU time in the decode benchmarks. I see some codegen issues that are relatively easy to fix, but DecodeBlockBaseline for example is a monster method once all of its callees are inlined, so it may take a bigger refactor to fully optimize that. Will start small and see where it goes...

[JimBobSquarePants]

I’ll be pushing a PR later which provides the inner loop build configuration and editorconfig fixes.