🤶🏼 👰🏽 ☝️ Dites mauvais mot pour LINQ 👽 😘 ➿

Pendant toute ma courte vie en tant que programmeur c #, j'ai pensé que LINQ ne concerne pas principalement les performances du code, mais les performances du programmeur, la vitesse à laquelle il écrit le code et non la vitesse à laquelle le processeur exécute ce code. Et les problèmes de performances du code et du programmeur sont résolus après avoir identifié les goulots d'étranglement. Par conséquent, j'écris souvent var groupedByDate = lst.GroupBy(item => item.IssueTime.Date).Select(…).ToList()et ne le fais pas à cause de dommages ou d'intentions malveillantes, mais il est tout simplement plus facile de déboguer le code. Pour la liste, placez simplement le curseur de la souris sur le texte de la variable et vous pouvez immédiatement voir s'il y a quelque chose ou non.

Début

Après avoir lu l'article «Article infructueux sur l'accélération de la réflexion » et calmé les émotions sur «quelqu'un a tort sur Internet», je me suis demandé s'il était possible de rendre le code «LINQ to Objects» proche des performances en «manuel». Pourquoi exactement LINQ to Objects? Dans mon travail, j'utilise souvent uniquement les fournisseurs LINQ to Objects et LINQ to Entities. La performance de LINQ to Entities n'est pas critique pour moi; il est essentiel à quel point la requête SQL générée sera optimale pour le serveur de base de données cible et à quelle vitesse le serveur l'exécutera.

Comme base, j'ai décidé d'utiliser le projet de l'auteur. Contrairement aux exemples tirés d'Internet, où un code est principalement comparé comme integerList.Where(item => item > 5).Sum()un code «manuel» contenant foreach, ifetc., l'exemple de l'article m'a paru intéressant et vital.

La première chose que j'ai faite a été d'utiliser une fonction de comparaison de chaîne unique. Dans le code source, dans les méthodes qui remplissent la même fonction, mais situées dans les coins opposés de l'anneau, différentes méthodes sont utilisées, dans un cas variable0.Equals(constant0, StringComparison.InvariantCultureIgnoreCase)et dans un autre variable0.ToUpperInvariant() ==constant0.ToUpperInvariant(). Il est particulièrement gênant pour la constante que chaque appel de méthode soit converti en majuscules. J'ai choisi la troisième option en utilisant dans les deux cas variable0.ToUpperInvariant() ==constant0InUpperCaseInvariant.

Ensuite, tout le code qui n'était pas directement lié à la comparaison des performances LINQ et du code manuel a été supprimé. Le premier à être intercepté était le code qui crée et initialise l'objet classe Mock<HabraDbContext>. Quel est l'intérêt de créer une connexion à la base de données pour chaque test, une fois suffit? Il a été déplacé au-delà des tests de performances.

IStorage _db;

[GlobalSetup]
public void Setup()
{
    _db = MockHelper.InstanceDb();
}

private IStorage DBInstance => _db;

… — , ! Linq «» !

« - » . LINQ . , — .

, , LINQ vs «» . . . .

, , , ([Params(1, 10, 100, 1000)]). . . . StatisticColumnRelStdDev.

— FastHydrationLinq, ManualHydrationLinq — . , , (Fast)(Manual)(Slow)HydrationLinq vs (Fast)(Manual)(Slow)Hydration, ManualHydrationLinq. FastHydrationLinq - . .

ToArray, ToDictionary IEnumerable<T> . , FastContactHydrator2. - Action<Contact, string> c ConcurrentDictionary<string, Action<Contact, string>> IEnumerable<KeyValuePair<string, Action<Contact, string>>>. GetContact2, Sum, .

protected override Contact GetContact2(IEnumerable<PropertyToValueCorrelation> correlations)
{
    var contact = new Contact();
    int dummySum = _propertySettersArray.Join(correlations, propItem => propItem.Key, corrItem => corrItem.PropertyName, (prop, corr) => { prop.Value(contact, corr.Value); return 1; }).Sum();
    return contact;
}

ParseWithLinq

public static IEnumerable<KeyValuePair<string, string>> ParseWithLinq2(string rawData, string keyValueDelimiter = ":", string pairDelimiter = ";")
    => rawData.Split(pairDelimiter)
    .Select(x => x.Split(keyValueDelimiter, StringSplitOptions.RemoveEmptyEntries))
    .Select(x => x.Length == 2 ? new KeyValuePair<string, string>(x[0].Trim(), x[1].Trim())
                                : new KeyValuePair<string, string>(_unrecognizedKey, x[0].Trim()));

FastContactHydrator2, , , , -, ( ParseWithLinq ParseWithoutLinq). . , , ToArray. 10 var result = new List<PropertyToValueCorrelation>(10). 10? 42 , 10 . Fair .

. . GetFakeData . , .
, , « » (RelStdDev). N=1000.

-  `ManualHydration`, `SlowHydration`, `FastHydration`, `ManualHydrationLinq`, `SlowHydrationLinq`, `FastHydrationLinq` -     ,  ;

ManualHydrationFair, ManualHydrationFairLinq, FastHydrationFairLinq — , ;
FastHydrationLinq2 — , , - , LINQ;
N , ;
Ratio FastHydrationLinq2.

Linq-

? — FastHydrationLinq2 ManualHydrationLinq Ratio. 26,361.37 μs 26,422.17 μs N=1000. / N. ManualHydrationFairLinq, 8% , . FastHydrationFairLinq, 1% -.

Fair-. , ManualHydrationFairLinq 8% . FastHydrationFairLinq FastHydrationLinq 12%. Linq .

, . . , MockHelper.InstanceDb() Setup, . — , GetFakeData, . , — . MockHelper.InstanceDb() .

N, MakeGarbage. False , True — .

Voilà, , . — N=1. 10% 82% .

… .

, , «» — Linq-, :

N=1 MakeGarbage=True «»

, , , LINQ .
«Gen X» «Allocated» N=1 MakeGarbage=True o , FastHydrationLinq2

|                                |      Gen 0 |   Gen 1 | Gen 2 |   Allocated |
|«»     |    20.5078 |  0.4883 |     - |    63.95 KB |
|Linq-        |    20.7520 |       - |     - |    63.69 KB |

ManualHydrationFairLinq .

. , , — .
, ? . , N [Params(1, 100)] MakeGargabe=True. «» — Linq-, . — , — Linq-, Linq — — — Linq. — . .

, , — Linq- . , . paint.net, . paint.net — paint.net . paint.net — «» , — Linq- .

— N 1, 10, 100, 1000 MakeGarbage [ParamsAllValues]. paint.net, — «» . — Linq- . paint.net Visual Studio — «» . , 80- . , Linq- 2%.

Après avoir écrit les tests et analysé les résultats, mon opinion sur LINQ n'a pas changé - en l'utilisant, ma productivité en écriture de code est plus élevée que sans elle; Les performances de LINQ to Objects sont satisfaisantes. L'utilisation retardée de l'exécution du code LINQ comme moyen d'améliorer les performances n'a pas beaucoup de sens.

Si dans un projet il y a des problèmes de performances dus au ramasse-miettes - la blessure à la naissance .net, alors le choix de cette technologie n'était probablement pas la meilleure solution.

Mon code de test est disponible ici .

Dites mauvais mot pour LINQ

Début

More articles: