Les classes scellées devraient fournir une amélioration des performances. Puisqu'une classe scellée ne peut pas être dérivée, tous les membres virtuels peuvent être transformés en membres non virtuels.

Bien sûr, nous parlons de très petits gains. Je ne marquerais pas une classe comme scellée juste pour obtenir une amélioration des performances à moins que le profilage ne révèle qu'il s'agit d'un problème.

Le marquage d'une classe sealed ne devrait avoir aucun impact sur les performances.

Il y a des cas où csc peut devoir émettre un opcode callvirt au lieu d'un opcode call. Cependant, il semble que ces cas soient rares.

Et il me semble que le JIT devrait pouvoir émettre le même appel de fonction non virtuel pour callvirt qu'il le ferait pour call, s'il sait que le la classe n'a pas (encore) de sous-classes. S'il n'existe qu'une seule implémentation de la méthode, il est inutile de charger son adresse à partir d'une vtable, il suffit d'appeler directement cette implémentation. D'ailleurs, le JIT peut même intégrer la fonction.

C'est un peu un pari de la part du JIT, car si une sous-classe est chargée plus tard, le JIT devra jeter ce code machine et compiler à nouveau le code, en émettant un véritable appel virtuel . Je suppose que cela n'arrive pas souvent dans la pratique.

(Et oui, les concepteurs de machines virtuelles recherchent vraiment de manière agressive ces minuscules gains de performances.)