Compilation peformance

[josephwoodward]

Hi,

I'm currently using Buildalyzer to generate an adhocworkspace and noticing that the initial compilation takes almost 40 seconds. The second run afterwards takes about 8 seconds, having done a bit of debugging it appears that it comes down to this line:

if (!projectInstance.Build("Compile", _logger == null ? null : new ILogger[] { _logger }))
{
    return null;
}

Is this level of performance expected, or could it be the way I'm using it, or are there any configuration options I can set to speed up compilation?

My usage seems pretty straight forward (see below), but I'm open to any suggestions as to what could be done to remove that initial 40 second penalty.

public static class WorkspaceManager
{
    public static Compilation LoadWorkspace(string filePath)
    {
        var manager = new AnalyzerManager();
        ProjectAnalyzer analyzer = manager.GetProject(filePath);

        var projectPath = analyzer.Project.DirectoryPath;

        var projects = analyzer.Project.Items.Where(x => x.ItemType == "ProjectReference");
        foreach (ProjectItem projItem in projects)
        {
            var p = Path.Combine(projectPath, projItem.EvaluatedInclude);
            analyzer.Manager.GetProject(p);    
        }
        
        Workspace workspace = analyzer.GetWorkspace(true);
        var compilation = workspace.CurrentSolution.Projects.FirstOrDefault().GetCompilationAsync().Result;
        return compilation;
    }
}

[daveaglick]

You might be hitting the deep nested path globbing problem (there's an issue or 3 on it somewhere). In a nutshell, the SDK isn't very good at resolving globbing patterns when there is a large nested path structure like node_modules. Any chance this applies? What's the target project look like?

[daveaglick]

Also - curious how long the target project takes to build if you run MSBuild on it from the command line? If there's a big variance between that and Buildalyzer then we might need to investigate missing properties or something...

[josephwoodward]

This is the .csproj file in question:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <UserSecretsId>aspnet-graphiql.example-D0705FC5-6A16-43BB-AE45-3C609BE0FE6A</UserSecretsId>
  </PropertyGroup>
  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="GraphQL" Version="0.17.3" />
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\graphiql\graphiql.csproj" />
  </ItemGroup>
</Project>

Running dotnet build on the project takes 8 - 9 seconds:

Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  graphiql -> /Users/josephwoodward/Dev/graphiql-dotnet/src/graphiql/bin/Debug/netstandard2.0/GraphiQL.dll
  graphiql.example -> /Users/josephwoodward/Dev/graphiql-dotnet/src/graphiql.example/bin/Debug/netcoreapp2.0/graphiql.example.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:08.50

[josephwoodward]

I'll try a few other projects to see if it's limited to that one.

[daveaglick]

That 40 second warm up certainly seems excessive. Anything stick out at you if you pass in a StringWriter to the manager ctor and bump the verbosity? I'll try to replicate tomorrow - I haven't used it against a .NET Core console app or an ASP.NET Core app yet, so maybe something about either of those. Might also be the NuGet tasks acting up given how large the dependency graph is on the ASP.NET Core metapackage.

[josephwoodward]

Interesting, a simple console application (dotnet new console) takes no time at all (1.3 seconds) and a new Web API (dotnet new webapi) takes 5 seconds, so it must be something about that project.

[daveaglick]

I'm going to go ahead and close this for now. To a large extent we're at the mercy of MSBuild - it'll take as long as it takes, particularly since Buildalyzer now runs the Restore target by default. That said, I would hope design-time builds like this don't ever take too long. I'll try to keep an eye on build times, particularly in the integration tests, to see if there's any odd outliers.