Après des années passées à jouer avec .net, il y a des syntaxes que l’on utilise instinctivement, et des pièges que l’on évite sans se poser la moindre question. Mais tous les ans il y a des nouveautés, de petits effets de mode, de grand chamboulement, ou des collègues qui vous font douter. Ajoutez à cela les améliorations continue de .net ...

Comment savoir aujourd’hui si le code que l’on écrit depuis des années est toujours aussi efficace ?

Comment savoir si un autre code est plus performant ?

Quels indicateurs choisir ?

À force de me poser ce genre de question, j’ai trouvé beaucoup de solutions (peut-être trop). Mais régulièrement, je me rendais compte que je me trompais (problème de warmup, ciblage du framework non pris en compte, impact sur le GC non mesurable…).

Jusqu’au jour où j’ai découvert BechmarkDotNet. Plusieurs années plus tard, cette librairie de benchmark répond toujours à mes besoins.

Pourquoi utiliser BenchmarkDotNet?

Avec BechmarkDotNet, je peux :

• Comparer l’exécution d’un même code avec plusieurs versions de .net framework ou .net core.
• Comparer l’exécution d’un même code en ciblant une plateforme x86 ou x64.
• Mesurer l’impact sur la mémoire et le GC.

Attention : BechmarkDotNet a bien d’autres possibilités. Je n’ai listé ici que ce qui m’intéresse le plus.

Je me limite volontairement à ces trois fonctionnalités pour une raison simple. Celles-ci me permettent de communiquer des résultats de benchmarks où l’on voit clairement que le contexte d’exécution a un impact. Elles me permettent aussi de mettre en avant l’impact qu’un code peut avoir sur le GC (ex: plus on alloue de mémoire et plus notre code est mauvais).

Si vous ne connaissez pas encore BechmarkDotNet, je vous encourage vivement à aller sur le site https://benchmarkdotnet.org/ et à utiliser le MemoryDiagnoser.

Dans un prochain article, j’indiquerai quelques erreurs à éviter lors de la création d’un benchmark, son exécution, et son analyse.

Conclusion

Aujourd’hui si vous vous demandez si vous devez utiliser une méthode ou une autre, pensez systématiquement à BechmarkDotNet.

Prenez cinq minutes pour coder un petit benchmark, vous ne le regretterez pas.

Après plusieurs années de service, .net core 2.1 tire sa révérence.

Si vous l'utilisiez encore, vous verrez le message suivant lors des mises jour de Visual Studio :

Dans le cas où vous n'auriez plus besoin de .net core 2.1, vous pouvez le désinstaller pour gagner quelques méga-octets.
Lors de la désinstallation des composants, pensez bien à commencer par "Outil de développement plus.net core 2.1", avant de décocher ".net core 2.1 Runtime"

J’entends souvent dire que les tests unitaires sont chronophages, difficiles à écrire ou à comprendre. Après chaque conversation sur le sujet, je me rends compte qu’une grande partie du problème est liée à l’outillage. Même si pour un développeur .net, Visual Studio simplifie les choses, il reste des zones d’ombres

Faire le choix de gRPC aujourd'hui, c'est faire le chois de la performance, de la modernité, et tout un tas de belles choses. Quand on se documente sur gRPC, on aurait presque l'impression qu'il n'y a que des avantages.

Attention : Spoiler alerte, l'article qui suit va peut-être vous éviter de faire de grosses erreurs.

Il existe un sujet qui peut poser des problèmes lors de la mise en production d'une application gRPC. Il s'agit de HTTP2. Ce standard n'est pas forcément supporté par votre OS, votre Runtime ou votre librairie gRPC. Voilà donc un sujet qu'il faut maitriser avant de se lancer.

Plutôt que de partir dans une longue litanie d'informations et détails indigestes, j'ai fait le choix de créer quelques tableaux. J'espère qu'ils seront suffisamment clairs et explicites.

Si comme moi vous avez eu la grande idée de vouloir mettre à jour Node.js, vous avez peut-être eu le droit à ce message d’erreur :

An error occured while applying security settings.

Authenticated Users is not a valid user or group. This could be a problem with the package, or a problem connecting to a domain controller on the network. Check your network connection and click Retry, or Cancel to end the install.

Ensuite, l’installation est annulée. Malheureusement, la version qui était déjà présente sur le PC a été désinstallée :(

Même si le message laisse penser que l’on pourrait avoir un problème sur son PC, il n’en est rien. L’installer de Node.js semble avoir un défaut. Une issue a été créée sur GitHub à ce sujet : Error: Users is not a valid user or group.

Comment s’en sortir?

En attendant un correctif, une solution de contournement a été proposée : il s’agirait d’installer NVM. Si l’on utilise WSL, pas de problèmes, la solution est intéressante. Dans le cas contraire, vous êtes dans l’impasse.

Si l’on veut rester dans un contexte 100% Windows, la solution passe par Chocolatey.

Voici la commande pour obtenir la dernière version de Node.js :

choco install nodejs

Et si vous préférez la version LTS :

choco install nodejs-lts