weixin_39654823
weixin_39654823
2020-12-27 13:55

Compilation peformance

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:

csharp
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.

csharp
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/Buildalyzer

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

7条回答

  • weixin_39564368 weixin_39564368 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39564368 weixin_39564368 4月前

    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?

    点赞 评论 复制链接分享
  • weixin_39564368 weixin_39564368 4月前

    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...

    点赞 评论 复制链接分享
  • weixin_39654823 weixin_39654823 4月前

    This is the .csproj file in question:

    xml
    <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\"></folder>
      </itemgroup>
      <itemgroup>
        <packagereference include="GraphQL" version="0.17.3"></packagereference>
        <packagereference include="Microsoft.AspNetCore.All" version="2.0.0"></packagereference>
      </itemgroup>
      <itemgroup>
        <projectreference include="..\graphiql\graphiql.csproj"></projectreference>
      </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
    
    点赞 评论 复制链接分享
  • weixin_39654823 weixin_39654823 4月前

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

    点赞 评论 复制链接分享
  • weixin_39564368 weixin_39564368 4月前

    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.

    点赞 评论 复制链接分享
  • weixin_39654823 weixin_39654823 4月前

    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.

    点赞 评论 复制链接分享

相关推荐