.net - studio - Rendimiento de compilación de Roslyn compilado por sí mismo: no es tan rápido como la versión original de Roslyn.

visual studio installer

Question

Lo que estoy haciendo en una oración

Comprobando la rama Update-1 del repositorio github de Roslyn , compilando csc.exe y compilando una solución aleatoria con la versión csc.exe que acabo de construir.

Resultado Esperado

Espero que el rendimiento sea comparable a la versión original de Roslyn que se envió con VS 2015 Actualización 1, ubicada en la ruta: C:/Program Files (x86)/MSBuild/14.0/Bin

Resultado actual

El rendimiento de compilación de la versión de Roslyn que construí yo mismo es significativamente peor, en comparación con el original. En la solución que utilicé en mis pruebas: aproximadamente 30 segundos frente a 65 segundos.

Mi procedimiento en más detalle

• Se clonó https://github.com/dotnet/roslyn.git y se comprobó la actualización de la sucursal-1
• Built Roslyn utilizando la configuración Release (probada con ambos, Mixed Configuration y x64 para la plataforma de solución).

• Para compilar una solución de prueba, modifiqué todos los archivos del proyecto para usar una ubicación específica para la ruta del csc:

  <CscToolPath>C:/Path/To/Output/Location/Of/Roslyn/Binaries/</CscToolPath>

• Para propósitos de prueba, estoy construyendo la solución de prueba desde la línea de comando con

  MSBuild.exe /t:Rebuild /m:1 /verbosity:m MySolutionName.sln

• Actualmente también estoy haciendo una limpieza antes:

  MSBuild.exe /t:Clean /m:1 /verbosity:m MySolutionName.sln

• Para probar contra el compilador original, enviado con VS 2015 Update 1, estoy cambiando la configuración en los archivos del proyecto a:

  <CscToolPath>C:/Program Files (x86)/MSBuild/14.0/Bin/</CscToolPath>

Preguntas

• ¿Qué puedo hacer para lograr un rendimiento similar con mi versión autocompilada de Roslyn, como con las dlls originales de Roslyn?
• ¿Hay alguna otra cosa (como optimizaciones, etc.) que deba tenerse en cuenta al construir Roslyn?

Answer 1

Además de la respuesta de Kevin, que es totalmente correcta, aquí hay algunos detalles más sobre la firma / NGEN compilación de binarios Roslyn, ya que esto puede ser interesante para otras personas.

• Para NGEN compilar los binarios, deben tener un nombre fuerte, lo que significa que deben estar firmados
• Normalmente, los binarios de Roslyn están firmados con la clave privada de Microsoft, como Kevin también señaló.
• Entonces, tenemos que usar nuestro propio par de claves para firmar
• La configuración correspondiente se puede encontrar en el repositorio de Roslyn en el archivo build / Targets / VSL.Imports.targets
• Para fines de prueba, podemos reemplazar esta sección:

<Choose>
    <When Condition="''$(SignAssembly)'' == ''true''">
      <Choose>
        <!-- Shipping binaries in an "official" build are delay-signed with the MS key; later, the signing
             system will finish the strong-name signing. -->
        <When Condition="''$(NonShipping)'' != ''true''">
          <PropertyGroup>
            <AssemblyOriginatorKeyFile>$(VSLToolsPath)/Strong Name Keys/35MSSharedLib1024.snk</AssemblyOriginatorKeyFile>
            <DelaySign>true</DelaySign>
            <PublicKey>0024000004800000940000000602000000240000525341310004000001000100b5fc90e7027f67871e773a8fde8938c81dd402ba65b9201d60593e96c492651e889cc13f1415ebb53fac1131ae0bd333c5ee6021672d9718ea31a8aebd0da0072f25d87dba6fc90ffd598ed4da35e44c398c454307e8e33b8426143daec9f596836f97c8f74750e5975c64e2189f45def46b2a2b1247adc3652bf5c308055da9</PublicKey>
            <PublicKeyToken>31BF3856AD364E35</PublicKeyToken>
          </PropertyGroup>
        </When>

        <!-- Non-shipping binaries are simply signed with the Roslyn internal key. -->
        <Otherwise>
          <PropertyGroup>
            <AssemblyOriginatorKeyFile>$(VSLToolsPath)/Strong Name Keys/RoslynInternalKey.Private.snk</AssemblyOriginatorKeyFile>
            <DelaySign>false</DelaySign>
            <PublicKey>$(RoslynInternalKey)</PublicKey>
            <PublicKeyToken>fc793a00266884fb</PublicKeyToken>
          </PropertyGroup>
        </Otherwise>
      </Choose>
    </When>
</Choose>

con, por ejemplo, este:

<Choose>  
<When Condition="''$(SignAssembly)'' == ''true''">
  <PropertyGroup>
    <AssemblyOriginatorKeyFile>C:/path/to/keyfile/TestKey.snk</AssemblyOriginatorKeyFile>
    <DelaySign>false</DelaySign>
    <PublicKey>0024000004800000940000000602000000240000525341310004000001000100B15B00E697DB995031A740A3E07A0B1DBE16AAEA61E615A013E0381B4D875F97F1792965D58810893F6D4B1C10CBD991FB8E9F1118D9C0C6F0EBCB50462FC25056E194667CB59822C18E9CB0C17DBC573291F05F7C87B51C48B377C9EEE12F6D5B331B235E5D6E3669737B210F7BE245A76B118C23EAD90FC392E4ED9F6CDFAB/PublicKey>
    <PublicKeyToken>6E0B9EF75D28854E</PublicKeyToken>
  </PropertyGroup>
</When>
</Choose>

• ... usando su propio archivo de clave, clave pública y token de clave pública.
• El archivo de clave se puede crear dentro de Visual Studio o con la ayuda de la herramienta sn.exe .
• sn.exe también se puede usar para exportar la clave pública y para extraer el token de la clave pública (por ejemplo, desde un ensamblaje que podría probar-firmar con la clave)

• Entonces NGEN se puede llamar así:

  ngen.exe install "C:/path/to/Roslyn/Release/csc.exe"

(por ejemplo, ubicado en C:/Windows/Microsoft.NET/Framework64/v4.0.30319/ngen.exe )

Answer 2

La mayor diferencia es que el compilador oficial instalado por Visual Studio en NGEN compilado como parte de la instalación.

Sin embargo, incluso si tiene NGEN, no obtendrá resultados exactamente equivalentes, porque Microsoft tiene datos de capacitación guiados por perfiles para admitir NGEN parcial, con el fin de obtener un buen equilibrio entre el tamaño binario y el tiempo JIT que no es parte del informe público. (similar a firmar con la clave privada oficial de Microsoft).