Performance sa .NET Core
Kumusta tanan! Kini nga artikulo usa ka koleksyon sa Labing Maayo nga Mga Praktis nga gigamit nako ug sa akong mga kauban sa dugay nga panahon sa pagtrabaho sa lainlaing mga proyekto.
Ang kasayuran bahin sa makina diin gihimo ang mga kalkulasyon:BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R), 1 CPU, 8 logical ug 4 physical cores
.NET Core SDK=3.0.100
[Host]: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
Core: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
[Host]: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT
Core: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT
Trabaho = Kinauyokan Runtime = Kinauyokan
ToList vs ToArray ug Cycles
Nagplano ko sa pag-andam niini nga impormasyon uban sa pagpagawas sa .NET Core 3.0, apan gibunalan nila ako niini, dili ko gusto nga mangawat sa himaya sa uban ug kopyahon ang impormasyon sa ubang mga tawo, mao nga ako lang itudlo .
Sa akong kaugalingon nga ngalan, gusto lang nako nga ipresentar kanimo ang akong mga sukod ug mga resulta; Gidugangan nako ang mga reverse loops sa kanila alang sa mga mahigugmaon sa "C++ style" sa pagsulat nga mga loop.
Code:
public class Bench
{
private List<int> _list;
private int[] _array;
[Params(100000, 10000000)] public int N;
[GlobalSetup]
public void Setup()
{
const int MIN = 1;
const int MAX = 10;
Random random = new Random();
_list = Enumerable.Repeat(0, N).Select(i => random.Next(MIN, MAX)).ToList();
_array = _list.ToArray();
}
[Benchmark]
public int ForList()
{
int total = 0;
for (int i = 0; i < _list.Count; i++)
{
total += _list[i];
}
return total;
}
[Benchmark]
public int ForListFromEnd()
{
int total = 0;t
for (int i = _list.Count-1; i > 0; i--)
{
total += _list[i];
}
return total;
}
[Benchmark]
public int ForeachList()
{
int total = 0;
foreach (int i in _list)
{
total += i;
}
return total;
}
[Benchmark]
public int ForeachArray()
{
int total = 0;
foreach (int i in _array)
{
total += i;
}
return total;
}
[Benchmark]
public int ForArray()
{
int total = 0;
for (int i = 0; i < _array.Length; i++)
{
total += _array[i];
}
return total;
}
[Benchmark]
public int ForArrayFromEnd()
{
int total = 0;
for (int i = _array.Length-1; i > 0; i--)
{
total += _array[i];
}
return total;
}
}
Ang katulin sa performance sa .NET Core 2.2 ug 3.0 halos parehas. Ania ang akong nakuha sa .NET Core 3.0:
Makahinapos kita nga ang pag-ulit nga pagproseso sa usa ka koleksyon sa Array mas paspas tungod sa mga internal nga pag-optimize ug klaro nga alokasyon sa gidak-on sa koleksyon. Angay usab nga hinumdoman nga ang usa ka koleksyon sa Listahan adunay kaugalingon nga mga bentaha ug kinahanglan nimo nga gamiton ang husto nga koleksyon depende sa gikinahanglan nga mga kalkulasyon. Bisan kung nagsulat ka og lohika alang sa pagtrabaho sa mga loop, ayaw kalimti nga kini usa ka ordinaryo nga loop ug kini usab gipailalom sa posible nga pag-optimize sa loop. Usa ka artikulo ang gipatik sa habr dugay na ang milabay: . May kalabotan gihapon kini ug girekomenda nga basahon.
Buang
Usa ka tuig ang milabay, nagtrabaho ko sa usa ka kompanya sa usa ka legacy nga proyekto, sa maong proyekto normal lang ang pagproseso sa field validation pinaagi sa try-catch-throw construct. Nasabtan na nako kaniadto nga kini dili maayo nga lohika sa negosyo alang sa proyekto, busa kung mahimo, gisulayan nako nga dili mogamit sa ingon nga disenyo. Apan atong mahibal-an kung ngano nga ang pamaagi sa pagdumala sa mga sayup sa ingon nga pagtukod dili maayo. Nagsulat ako usa ka gamay nga code aron itandi ang duha nga mga pamaagi ug naghimo mga benchmark alang sa matag kapilian.
Code:
public bool ContainsHash()
{
bool result = false;
foreach (var file in _files)
{
var extension = Path.GetExtension(file);
if (_hash.Contains(extension))
result = true;
}
return result;
}
public bool ContainsHashTryCatch()
{
bool result = false;
try
{
foreach (var file in _files)
{
var extension = Path.GetExtension(file);
if (_hash.Contains(extension))
result = true;
}
if(!result)
throw new Exception("false");
}
catch (Exception e)
{
result = false;
}
return result;
}Ang mga resulta sa .NET Core 3.0 ug Core 2.2 adunay susama nga resulta (.NET Core 3.0):
Ang try catch naghimo sa code nga mas lisud sabton ug nagdugang sa execution time sa imong program. Apan kung kinahanglan nimo kini nga pagtukod, dili nimo kinahanglan nga isulod ang mga linya sa code nga wala gilauman nga magdumala sa mga sayup - kini maghimo sa code nga dali masabtan. Sa tinuud, dili kaayo ang pagdumala sa mga eksepsiyon nga nagkarga sa sistema, apan ang paglabay sa mga sayup mismo pinaagi sa paglabay sa bag-ong Exception construct.
Ang paglabay sa mga eksepsiyon mas hinay kay sa pipila ka klase nga mokolekta sa sayop sa gikinahanglang pormat. Kung nagproseso ka og usa ka porma o pipila ka datos ug klaro ka nga nahibal-an kung unsa ang sayup, nganong dili kini iproseso?
Dili ka kinahanglan magsulat og usa ka paglabay sa bag-ong Exception() construct kung kini nga sitwasyon dili talagsaon. Ang pagdumala ug paglabay sa usa ka eksepsiyon mahal kaayo!!!
ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant
Sulod sa akong 5 ka tuig nga kasinatian sa pagtrabaho sa .NET nga plataporma, nakasugat ko og daghang mga proyekto nga migamit og string matching. Nakita usab nako ang mosunod nga hulagway: adunay usa ka Enterprise nga solusyon nga adunay daghang mga proyekto, nga ang matag usa naghimo sa mga pagtandi sa string nga lahi. Apan unsa ang angay gamiton ug unsaon kini paghiusa? Sa librong CLR pinaagi sa C# ni Richter, nakabasa kog impormasyon nga ang ToUpperInvariant() nga pamaagi mas paspas kay sa ToLowerInvariant().
Kinutlo gikan sa libro:
Siyempre, wala ko motuo niini ug nakahukom sa pagdagan sa pipila ka mga pagsulay unya sa .NET Framework ug ang resulta nakurat kanako - labaw pa sa 15% nga pagtaas sa performance. Dayon, sa pag-abot sa trabahoan pagkasunod buntag, akong gipakita kini nga mga sukod sa akong mga superyor ug gihatagan sila og access sa source code. Pagkahuman niini, 2 sa 14 nga mga proyekto ang gibag-o aron ma-accommodate ang mga bag-ong sukod, ug kung gikonsiderar nga kini nga duha nga mga proyekto naglungtad aron maproseso ang daghang mga lamesa sa Excel, ang sangputanan labi ka hinungdanon alang sa produkto.
Gipresentar ko usab kaninyo ang mga sukod alang sa lain-laing mga bersyon sa .NET Core, aron ang matag usa kaninyo makahimo sa pagpili sa labing maayo nga solusyon. Ug gusto lang nako idugang nga sa kompanya kung diin ako nagtrabaho, gigamit namon ang ToUpper () aron itandi ang mga kuwerdas.
Code:
public const string defaultString = "VXTDuob5YhummuDq1PPXOHE4PbrRjYfBjcHdFs8UcKSAHOCGievbUItWhU3ovCmRALgdZUG1CB0sQ4iMj8Z1ZfkML2owvfkOKxBCoFUAN4VLd4I8ietmlsS5PtdQEn6zEgy1uCVZXiXuubd0xM5ONVZBqDu6nOVq1GQloEjeRN8jXrj0MVUexB9aIECs7caKGddpuut3";
[Benchmark]
public bool ToLower()
{
return defaultString.ToLower() == defaultString.ToLower();
}
[Benchmark]
public bool ToLowerInvariant()
{
return defaultString.ToLowerInvariant() == defaultString.ToLowerInvariant();
}
[Benchmark]
public bool ToUpper()
{
return defaultString.ToUpper() == defaultString.ToUpper();
}
[Benchmark]
public bool ToUpperInvariant()
{
return defaultString.ToUpperInvariant() == defaultString.ToUpperInvariant();
}
Sa .NET Core 3.0, ang pagtaas sa matag usa niini nga mga pamaagi mao ang ~x2 ug gibalanse ang mga pagpatuman sa ilang kaugalingon.
Tier Compilation
Sa akong katapusan nga artikulo akong gihulagway kini nga pag-andar sa makadiyot, gusto nako nga matul-id ug madugangan ang akong mga pulong. Ang multi-level compilation nagpadali sa oras sa pagsugod sa imong solusyon, apan imong gisakripisyo nga ang mga bahin sa imong code i-compile sa usa ka mas optimized nga bersyon sa background, nga makapaila sa gamay nga overhead. Uban sa pag-abut sa NET Core 3.0, ang oras sa pagtukod alang sa mga proyekto nga adunay lebel sa pag-compile nga nahimo mikunhod ug ang mga bug nga adunay kalabotan sa kini nga teknolohiya naayo na. Kaniadto, kini nga teknolohiya misangpot sa mga kasaypanan sa unang mga hangyo sa ASP.NET Core ug nag-freeze sa panahon sa unang pagtukod sa multi-level compilation mode. Sa pagkakaron kini gi-enable pinaagi sa default sa .NET Core 3.0, apan mahimo nimo kining i-disable kung gusto nimo. Kung naa ka sa posisyon nga nanguna sa team, senior, tunga-tunga, o ikaw ang pinuno sa usa ka departamento, nan kinahanglan nimong masabtan nga ang paspas nga pag-uswag sa proyekto nagdugang ang kantidad sa team ug kini nga teknolohiya magtugot kanimo nga makatipig oras alang sa duha nga mga developer. ug ang panahon sa proyekto mismo.
.NET level up
I-upgrade ang imong .NET Framework / .NET Core nga bersyon. Kasagaran, ang matag bag-ong bersyon naghatag dugang nga mga kadaugan sa pasundayag ug nagdugang bag-ong mga bahin.
Apan unsa gyud ang mga kaayohan? Atong tan-awon ang pipila niini:
- Ang .NET Core 3.0 nagpaila sa R2R nga mga hulagway nga makapakunhod sa oras sa pagsugod sa .NET Core nga mga aplikasyon.
- Uban sa bersyon 2.2, nagpakita ang Tier Compilation, salamat kung diin ang mga programmer mogugol ug gamay nga oras sa paglansad sa usa ka proyekto.
- Suporta para sa bag-ong .NET Standards.
- Suporta alang sa bag-ong bersyon sa programming language.
- Pag-optimize, sa matag bag-ong bersyon ang pag-optimize sa mga base nga librarya Collection/Struct/Stream/String/Regex ug daghan pa nga molambo. Kung molalin ka gikan sa .NET Framework ngadto sa .NET Core, makakuha ka og dako nga pag-uswag sa performance gikan sa kahon. Isip usa ka pananglitan, nag-attach ko og link sa pipila ka mga optimization nga gidugang sa .NET Core 3.0:
konklusyon
Kung nagsulat og code, angay nga hatagan pagtagad ang lainlaing mga aspeto sa imong proyekto ug gamiton ang mga bahin sa imong programming language ug platform aron makab-ot ang labing kaayo nga sangputanan. Malipay ko kung ipaambit nimo ang imong kahibalo nga may kalabotan sa pag-optimize sa .NET.
Source: www.habr.com