La sérialisation XML est lente

Question

J'ai hérité d'un projet dans lequel le modèle de données de l'application est un document XML. Les développeurs avant moi avaient créé un modèle d'objet basé sur le schéma de ce xml, puis codé par rapport au modèle d'objet.

Après plusieurs années de maintenance, cette application a progressivement commencé à montrer son âge. Le chef d'équipe a dit que la principale raison derrière cela est due à la «lenteur» de la sérialisation xml. Je suis tenté d'appeler BS sur ce sujet, mais la plupart des fichiers XML que nous traitons ont une taille de plus de 2MB, et en gardant à l'esprit les bases de ce qui se passe dans les coulisses avec des objets marqués [Serializable], 2MB il pourrait donc y avoir une part de vérité dans la théorie de la lenteur. D'après votre expérience, la sérialisation est-elle vraiment si "lente"/mauvaise que d'opter pour un modèle XML -> XPath au lieu d'un modèle XML -> POCO?

BTW il s'agit d'un projet .NET 2.0, et nos clients pourraient passer à .NET 3.5 vers la fin de l'année prochaine.

Answer 1

En général, non, je ne pense pas que le ralentissement soit dû à la sérialisation XML; 2MB n'est pas très grand, et cela ne devrait pas causer de ralentissement majeur. Ce qui m'inquiète le plus, c'est que le chef d'équipe vous dise de quoi le ralentissement est dû sans vous donner d'informations de profilage spécifiques, vous montrant que c'est le cas. Les opinions sur l'optimisation sont souvent fausses; le profilage existe dans le but de trouver précisément où tout ralentissement se passe dans une application. Je recommande d'instrumentation et profilage de l'application, et de trouver où le ralentissement est; Je parie que ce n'est pas dans la sérialisation XML.

Answer 2

Xml La sérialisation n'utilise pas l'attribut Serializable. Le sérialiseur xml génère en fait un assembly qui mappe le xml à l'objet, il n'utilise pas de réflexion. C'est l'une des raisons pour lesquelles la sérialisation Xml ne fonctionne qu'avec les publics.

Une chose que vous pouvez essayer est de mesurer en utilisant le DataContractSerializer qui fait partie de WCF. Ce serait intéressant de voir la différence.

Je n'ai jamais rencontré personnellement de limitation de performance, mais je n'ai pas non plus d'objets volumineux tels que votre description. Une chose à surveiller est le constructeur que vous utilisez pour créer le XmlSerializer, certains d'entre eux ne mettent pas en cache l'assemblage généré et entraîneront une perte de performance et une fuite de mémoire car chaque appel générera de plus en plus d'assemblages . Si c'est le cas, vous avez deux options:

1) Mettre en cache l'instance de sérialiseur que vous avez créée. Je crois que c'est thread sûr, mais vous voudrez vérifier MSDN.
2) Utiliser un constructeur différent pour créer le XmlSerializer.

Answer 3

Exécuter un profileur et voir où la plus grande partie du temps CPU est passé. Qu'il s'agisse de la sérialisation XML ou d'ailleurs, vous saurez où concentrer vos efforts. Aussi, pour mémoire, j'ai vu la sérialisation XML étonnamment lente dans le passé dans le monde Java en travaillant avec Spring RPC. Donc, il est certainement possible que votre patron ait raison, mais plutôt que de deviner, vous devriez vérifier.

Answer 4

Comme cela n'a pas encore été mentionné, j'ai pensé qu'il y avait une option dans VS pour générer des assemblages de sérialisation XML au moment de la construction.

http://msdn.microsoft.com/en-us/library/kb4wyys2(v=VS.100).aspx

Vous pouvez également utiliser sgen.exe manuellement pour faire la génération si vous voulez un contrôle plus fin. Cela réduit le temps nécessaire pour sérialiser un type car, comme l'explique JoshBerke, XmlSerialiser génère un nouvel assemblage chaque fois qu'il a besoin de le sérialiser ou de le désérialiser, ce qui peut prendre du temps pour les types complexes. La pré-génération de vos assemblages de sérialisation peut ainsi entraîner des améliorations significatives des performances.