Nous essayions de trier une collection d'objets FileInfo dans .NET. Nous avons implémenté IComparer pour nous assurer que les objets FileInfo ont été triés en fonction de nos critères. Nous avons ensuite remarqué que les performances de tri des objets FileInfo étaient plusieurs fois plus lentes que les simples. Sur une intuition (et en nous rappelant comment les références fonctionnent en C), nous avons pu améliorer les performances en utilisant des variables locales pour limiter le nombre de fois que nous avons référencé les propriétés FileInfo. Mon idée était que les variables locales seraient plus rapides à accéder que les propriétés sur les objets. Je pense que cela a du sens dans le monde du code non géré, où je peux réellement imaginer comment la pile fonctionne et comment les valeurs sont référencées. Cependant, je sais que le monde du code managé peut être plus compliqué sous les couvertures. Ma question est: Est-ce que ces idées de base de la gestion de la mémoire et du flux de programmes dans le code non géré peuvent être projetées dans le monde du code managé? Par la suite, avec l'aide de KeeperOfTheSoul, nous avons pu suivre la façon dont nous nous moquions de l'objet FileInfo. Pour cette raison, j'ai ajouté un tag RhinoMock à cette question.Performances du type de référence de tri par rapport aux types de valeur
Répondre
Il ne devrait pas vraiment y avoir de différence de vitesse entre le tri d'un type de valeur par rapport à un type de référence sauf pour la mise en œuvre de la méthode de comparaison. Si je mettais en place une méthode de comparaison utilisant le péché, les ints seraient également triés lentement.
L'accès à une propriété implique un appel de méthode, tandis que l'accès à une variable locale, soit la valeur est directement sur la pile ou déjà dans un registre. Cependant, les propriétés simples peuvent être optimisées par le JIT pour fournir quelque chose de similaire à l'inline.
Dans ce cas, je pense que le problème est que FileInfo peut exiger une lecture du système de fichiers pour obtenir la valeur des propriétés, et si FileInfo ne cache pas la valeur, il peut répéter cette opération plusieurs fois.
Je ne pense pas que l'objet FileInfo accède directement au système de fichiers. Dans notre test, nous nous moquions des objets FileInfo en utilisant RhinoMock. Cela nous amène à un bon point, est-ce que ce pourrait être le framework RhinoMock qui ralentissait nos tests? – LJM
Probablement, je pense que rhino mock le place à travers une réflexion, certainement assez pour arrêter les optimisations JIT d'être aussi efficace. –
Je viens de faire quelques tests pour vérifier et cela ressemble certainement à des performances sur les objets mockés. Merci pour l'aide. – LJM