.NET zoo bajo el prisma de NET Core

Hola a todos! Hoy observamos los diversos chips y cambios que han aparecido en la plataforma .NET Core y los comparamos con el Framework. Rompí el artículo en módulos para una mejor comprensión. Este artículo será interesante para quienes van a cambiar a .NET Core o ya lo están utilizando.

Tecnología de pila


Actualmente tenemos tres plataformas: .NET Framework, Mono y .NET Core. Cada plataforma incluye las siguientes tecnologías:

NET Framework - WPF, WinForms, ASP.NET (implementación DNX), WCF
NET Core - UWP, ASP.NET Core, WA, Xamarin (.NET Standard), Avalonia y otros
Mono - Xamarin (PCL, proyecto Share), Unity, ASP.NET, WinForms (multiplataforma)
NET Core (3.0) : todo es lo mismo que .NET Core arriba + WPF y WinForms, ML.NET

NET estándar


También hay un estándar .NET. Este es un conjunto de clases, métodos e interfaces que le permiten escribir y usar código común para todas las plataformas enumeradas anteriormente. También puede escribir aplicaciones de consola en él. En resumen, esta es la misma PCL, pero funciona en todas las plataformas enumeradas anteriormente.

Plataforma cruzada


No enfocaré su atención en esto, simplemente enumeraré el soporte del sistema operativo para los proyectos NET Core:

Windows
Linux
MacOS

Además admite el lanzamiento bajo procesadores ARM en Linux y Windows.

Dependencia


Como parte de la compatibilidad cruzada, la plataforma de desarrollo de aplicaciones incluye una infraestructura modular. Se emite a través de NuGet, y puede acceder a las funciones de lote, en lugar de a un conjunto grande. Como desarrollador, puede crear aplicaciones livianas que contengan solo los paquetes NuGet necesarios, lo que hará que su programa sea más seguro y productivo.

La infraestructura modular también permite actualizaciones más rápidas de la plataforma .NET Core, ya que los módulos afectados pueden actualizarse y lanzarse individualmente.

Csproj


Ahora profundicemos y veamos con más detalle lo que tenemos debajo del capó en los proyectos. Al crear un nuevo proyecto, cada uno de ustedes se encontró con el archivo MyProject1.csproj (el nombre puede ser diferente). Este archivo es responsable de la configuración de compilación para este proyecto, dependencias de otros proyectos o bibliotecas (bibliotecas) y mucho más.

Tengo un ejemplo de cómo decidí reescribir un proyecto a .NET Standard. Echemos un vistazo a cómo era antes (Framework):



Desafortunadamente, este archivo no cabe en mi PC por completo (todavía hay referencias). Y ahora veamos cómo se convirtió después de la transferencia:



En NET Core y .NET Standard, csproj se ha simplificado enormemente. Particularmente los "balísticos" pueden notar que algunos han cambiado. Eliminé lo innecesario y lo reemplacé con herramientas más convenientes. Después de reescribir csproj, noté que trabajar con paquetes NuGet comenzó a tomar notablemente menos tiempo y, como comprenderán, editar la nueva versión de csproj es mucho más conveniente, ya que no está abarrotado de líneas adicionales.

Rendimiento y mejoras


Aleatorio modificado
HttpClient modificado
Ciclos optimizados
Lista optimizada, matriz
Stream optimizado, MemoryStream
Y mucho más

En este artículo no consideraré todos los cambios. Este será un artículo separado. Pero veamos un pequeño ejemplo en la colección List:

var list = new List<int>(); for (int i = 0; i < 100000000; i++) { list.Add(i); list.RemoveAt(0); } 

Lo ejecuté a través de benchmarkdotnet.org en ambas plataformas. Después de las pruebas, obtuve los siguientes resultados:

Core 2.2.4 x64 RyuJIT
Método : BenchmarkList
Media : 370,1 ms
Error : 0.3761 ms
StdDev : 0.3518 ms

Marco 4.7.2 x64 RyuJIT
Método : BenchmarkList
Media : 481,9 ms
Error : 1.210 ms
StdDev : 1.011 ms

Como puede ver, la velocidad de operación es significativamente diferente (a veces) a favor de Core.

Microsoft está tratando no solo de proporcionar a los desarrolladores herramientas de desarrollo convenientes, sino que también mejora las cosas básicas que conducen a mejoras y optimizaciones de sus proyectos.

Compilación de niveles


Esta es una característica que hace que el tiempo de ejecución sea más adaptable para usar el compilador JIT para mejorar el rendimiento de inicio y maximizar el rendimiento.

 <Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>netcoreapp2.2</TargetFramework> <LangVersion>7.3</LangVersion> <!--      --> <TieredCompilation>true</TieredCompilation> <Platforms>AnyCPU;x64</Platforms> </PropertyGroup> </Project> 

Compila el proyecto lo más rápido posible.

Optimiza los métodos más comunes.

Esta funcionalidad hace que su proyecto se desarrolle más rápido y le brinda casi el mismo rendimiento. Probamos esta funcionalidad, y esta es una característica inteligente para proyectos NET Core, que reduce el tiempo de compilación. La compilación multinivel ralentiza ligeramente el funcionamiento de su aplicación, no recomiendo incluirla en un servidor de producción, pero para la depuración hay más de una función real que ahorra tiempo a los programadores.

Conclusión


Microsoft está tratando de mejorar la vida de los desarrolladores de la plataforma .NET. Todos los "productos" anteriores que han aparecido en nuestra empresa nos permiten hacer que el entorno sea más abierto y ampliable. Espero que lo aprecies No tenga miedo de cambiar a una nueva pila de tecnología y usar diferentes funciones.

Gracias por su atencion Espero que lo hayas disfrutado.

Source: https://habr.com/ru/post/451084/


All Articles