|
Il arrive souvent en effet que nous ayons besoin de construire une chaîne de caractères
à partir d'éléments divers comme par exemple pour la création d'une requête
SQL. Le framework .NET dans un souci de sécurité crée les chaînes de caractères
dans un mode immuable, c'est à dire qu'il est impossible d'écrire quoi
que ce soit dans l'espace mémoire de nos chaîne de caractères.
Mais que se passe-t-il quand on concatène des chaînes pour en obtenir une nouvelle.
En fait, le framework va créer une nouvelle chaîne de caractères à partir de deux
parties puis ainsi de suite jusqu'à obtention du résultat. On peut donc déduire
que dès que l'on a plus de deux éléments à concaténer, on a donc des allocations
mémoires supplémentaires.
Même si le garbage collector est notre ami gardons à l'esprit deux choses :
- Une allocation mémoire a un coût en terme de performance.
- Une allocation/désallocation mémoire fragmente cette dernière.
Pour parer à cet inconvénient, le framework contient une classe nommée StringBuilder.
Cette dernière permet la composition de chaînes de caractères en travaillant dans
un buffer mémoire afin de limiter les allocations et copies de données superflues.
A partir de quand faut-il choisir un StringBuilder plutôt qu'une concaténation
standard ? En effet, il ne faut pas négliger le coût de construction du StringBuilder
ainsi que la conversion du buffer en chaîne de caractères.
Voici un tableau récapitulatif:
| 1 | 2 | 3 | 4 | 5 | 10 | 15 | 20 | | Concaténation | 7ms | 61ms | 115ms | 182ms | 280ms | 728ms | 1242ms | 1864ms | | StringBuilder | 93ms | 123ms | 238ms | 239ms | 266ms | 524ms | 672ms | 824ms |
|