À plusieurs reprises il m’est arrivé d’atteindre des limites peu connues en utilisant le .NET framework.

Récemment encore, en travaillant sur un problème d’optimisation, j’avais mis en place un algorithme de type BFS afin de chercher la solution la plus efficace à un problème. Du fait de l’explosion combinatoire du problème, mon pauvre programme pourtant en mode 64 bits tombait sur une exception de type « mémoire insuffisante« . Le souci est qu’au moment de l’exception, mon programme consommait à peine 10 Go de mémoire et qu’il me restait 16 Go de libre sur ma machine de 32 Go. Rageant.

Exception mémoire d'un programme basé sur .NET framework
Exception mémoire d’un programme 64 bits basé sur .NET framework. On voit sur le panneau à droite que le programme a planté après avoir consommé « seulement » 10 Go

Comme je travaille de plus en plus avec le .NET core, aussi bien sous Windows que sous Linux, j’ai voulu tester mon programme en le basculant pour .NET core 5 et voir s’il y avait des différences en terme de performance et d’occupation mémoire. Je n’ai pas spécialement noté de différence sur ces 2 aspects là, mais j’ai découvert une différence majeure : plus d’exception. J’ai même pu laisser filer mon programme au-delà de la mémoire disponible (process testé à 44 Go avec 32 Go de RAM), Windows restant imperturbable.

Aucun problème mémoire d'un programme basé sur .NET core
Le même programme 64 bits que précédemment revu pour .NET core. Plus de problème de mémoire. On voit sur le panneau à droite que le process continue après avoir consommé 29 Go sur une machine de 32 Go

En conclusion, tout nouveau développement en C# devrait cibler sans hésiter .NET Core au lieu de .NET framework, vu l’ensemble des avantages (notamment l’aspect multi-plateforme) et l’absence de perte.