Je ne veux pas commencer une guerre de flamme sur la micro-optimisation, mais je suis curieux de quelque chose.
Quelle est la tête en termes de mémoire et de performance de la création d'instances d'un type qui n'a aucune donnée intrinsèque?
Par exemple, une classe simple qui implémente exemple typique code que j'ai vu juste des appels Je ne peux pas imaginer que le coût d'instanciation ici est beaucoup du tout, mais je suis intéressé de savoir ce que c'est réellement. Et comment cela se comparerait-il à une classe d'usine statique qui maintient un dictionnaire de types à des comparateurs afin qu'une instance de comparaison puisse être utilisée partout, elle est nécessaire. icomparer comparer méthode et aucune propriété ou champs. nouveau foocomparer () , partout où l'un de ceux-ci est nécessaire.
3 Réponses :
Au minimum, un objet de classe aura toujours un pointeur sur ses informations de type et certaines informations de ménage, même si elle n'a pas de membres de données.
selon Sur un système 32 bits, chaque objet dispose d'un en-tête de 8 octets [...] sur des systèmes 64 bits, la situation est pire. L'en-tête d'objet est augmenté à 16 octets.
Il y a des frais généraux, mais il est probablement négligeable par rapport à ce que vous allez utiliser le comparateur pour.
sur un système 32 bits et 64 bits que l'instance utilisera 16 octets d'espace de tas. Les frais généraux sont deux pointeurs, qui utilisent 8 octets sur un système 32 bits et 16 octets sur un système 64 bits. Cependant, le gestionnaire de mémoire dans le système 32 bits ne peut pas affecter des blocs inférieurs à 16 octets. Il y aura donc 8 octets inutilisés dans le bloc.
Si vous réutilisez beaucoup ces comparateurs, vous pourriez envisager de les garder. Toutefois, vous devez également considérer que les objets de courte durée vivent provoquent beaucoup moins de contraintes sur la gestion de la mémoire que les objets de longue durée de vie. Vous devez donc réutiliser les comparateurs pour qu'il en vaut la peine de les valoriser.
Ceci n'est que tangentiellement lié à votre question, mais si vous utilisez C # 3.0 ou plus, vous pouvez utiliser ce motif: et utiliser comme si: P> var fooComparer = new AdhocComparer<Foo>( (x, y) => /* do stuff */);
Si vous avez fabriqué
comparer statique, il n'y aurait pas de frais généraux, ce ne serait pas comme une fonction gratuite des messages de noms.@Kerrek: Et si vous l'avez fait, le code refuserait de compiler. Cette méthode est requise par l'interface
@Kerrek, le point de la classe doit mettre en œuvre
icomparer , que vous ne pouvez pas faire avec la méthode statique. Oh ok, je vois. Dans ce cas, il y aurait une certaine quantité de surcharge des appels virtuels et de ces pointeurs, je suppose.
Je dois dire que le manque de fonctions libres dans C # me fait de me manquer dans des langues comme C ++ et de telle sorte que ce soit le soutien. Autre que ça, j'adore c #.
@Mike, je pense que les méthodes statiques sont suffisamment proches pour tout ce que vous utiliseriez des fonctions en C ++.