MSBuild is still opt'ing into the legacy GetFullPath behavior

[davkean]

.NET Framework recently made a change in 4.6.2 that improved the overhead of Path.GetFullPath by reducing the amount of processing within .NET itself, and letting it be handled by the operating system.

While MSBuild has their own version of GetFullPath (which should also be considered to be moved to the new GetFullPath), they are indirectly using the legacy behavior via Directory.GetFiles/GetDirectories, MSBuild should opt into the new behavior when running on 4.6.2 and above:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
  </runtime>
</configuration>

[davkean]

Did some quick analysis over 100,000 items:

Method	Mean	Error	StdDev	Gen 0	Allocated
GetFullPath_New	263.9 ms	1.344 ms	1.191 ms	8187.5000	32.81 MB
GetFullPath_Legacy	318.0 ms	0.7823 ms	0.6935 ms	9500.0000	38.15 MB

[davkean]

In this trace for this: dotnet/sdk#1432 (comment), normalizing the path for GetFiles/GetDirectories was ~2.0% of the overall CPU time:

[rainersigwald]

Oh, that's a distinct switch from Switch.System.IO.BlockLongPaths which is more complicated for us to adopt.

This should be pretty doable for us--I doubt anyone was passing things through MSBuild that were confusingly handled extended file attributes or anything.

[davkean]

Note, there's more here around allocations (the new one is much friendly to the GC):

[davkean]

Here's another trace, we can remove the indicated frames by opt'ing into the new behavior:

[davkean]

Even for a project with zero globs, we're hitting this just loading all the props/targets in the graph:

[rainersigwald]

To get benefits for design-time, we'd need this in devenv.exe.config too, which would also affect extensions. I'm not sure what the right way to do that and validate that it's ok is--do you know?