Je travaille sur une application de cadre compact et je dois renforcer les performances. L'application fonctionne actuellement hors ligne en sérialisant des objets sur XML et en les stockant dans une base de données. À l'aide d'un outil de profilage, je pouvais voir que c'était un grand nombre de frais généraux, ralentissant l'application. Je pensais que si je suis passée à une série de sérialisation binaire, la performance augmenterait, mais parce que cela n'est pas pris en charge dans le cadre compact, j'ai examiné Protobuf-net. La sérialisation semble plus rapide, mais la désérialisation beaucoup plus lente et l'application fait plus de désérialisation que la sérialisation.
Si la sérialisation binaire devrait être plus rapide et si oui, ce que je peux faire pour accélérer la performance? Voici un extrait de la manière dont j'utilise à la fois xml et binaire:
sérialisation XML: sérialisation binaire de protocouds-net: < Pré> xxx
6 Réponses :
intéressant ... pensées:
délégué.createdélégate qui permet à Protobuf-net d'accéder aux propriétés beaucoup plus rapidement que dans la boîte de CF 2.0
- Êtes-vous d'annotant champs ou propriétés ? Encore une fois, dans les FC, les optimisations de réflexion sont limitées; Vous pouvez obtenir des performances de BÉTER dans cf 3.5 avec Propriétés , comme avec un champ La seule option que j'ai disponible est
fieldinfo.sevalue
Il y a un certain nombre d'autres choses qui n'existent tout simplement pas dans CF, il doit donc faire des compromis dans quelques endroits. Pour des modèles trop complexes, il existe également un problème connu avec les limitations de génériques de cf . Un correctif est en cours, mais c'est un changement gros , et prend "un certain temps".
Pour info, quelques métriques sur régulier (complet) .NET comparant divers formats (y compris xmlSerializer et protobuf-net) sont ici .
J'utilise CF2.0, et j'ai ajouté des attributs aux propriétés des objets dont j'ai besoin pour sérialiser.
Est-il possible de l'essayer dans cf 3.5 (avec le binaire CF 3,5) juste pour voir si cela le corrige?
OK, je viens de courir mon test sur la CF3.5 et de voir une augmentation significative des performances de CF2; Binary effectue beaucoup plus rapidement pour la sérialisation et la désérialisation. Malheureusement, je suis attaché à cf2 si elle devrait avoir besoin de repenser les choses.
Juste pour clarifier mon libellé ci-dessus .. Je veux dire, je vois des augmentations de performance significatives dans la CF3.5; CF2 est plus lent.
Désolé..scratch ça, j'ai lu le rapport de perf. Voici ce que je vais tester une entité simple avec 3 propriétés: XML Serialize 317MS XML désérialisze: 7ms binaire Serialize: 147ms binaires désérialisé: 19ms
Est-ce que cela est en moyenne sur un certain nombre d'itérations? Je ne sais pas non plus si ces chiffres sont CF2 ou CF3.5
Les résultats d'un test, mais sortent très similaires à chaque fois. C'est sur 3,5
Pour info, la première itération a les frais généraux de la construction du modèle - les appels ultérieurs peuvent être plus rapides ... je suis intrigué qu'il est plus lent que xmlSerializer. J'aimerais bien le tirer ;-(
Avez-vous essayé de créer des classes de sérialisation personnalisées pour vos cours? Au lieu d'utiliser XMLSerializer, ce qui est un sérialisateur général (il crée un tas de classes au moment de l'exécution). Il y a un outil pour faire cela (SGen). Vous l'exécutez pendant votre processus de construction et génère un ensemble personnalisé pouvant être utilisé en rythme de XMLSérialisateur.
Si vous avez Visual Studio, l'option est disponible sous l'onglet Construction des propriétés de votre projet.
est la performance touchée dans la sérialisation des objets ou les écrivez à la base de données? Depuis que les écrit, ils frappent probablement une sorte de rangement lent, j'imagine que c'est un coup beaucoup plus grand que l'étape de sérialisation.
Gardez à l'esprit que les mesures PERF postées par Marc Gravell testent la performance supérieure à 1 000 000 itérations.
Quel type de base de données vous stockez-vous? Les objets sont-ils sérialisés en mémoire ou directement au stockage? Comment sont-ils envoyés à la DB? Quelle est la taille des objets? Quand on est mis à jour, envoyez-vous tous les objets à la base de données ou simplement celui qui a changé? Êtes-vous en train de mettre en cache quelque chose en mémoire ou de relecture de stockage à chaque fois?
Les objets sont stockés dans une base de données SQLCE, mais je peux clairement voir que la sérialisation et la désérialisation sont le succès de la performance, et non l'interaction de la base de données. Des trucs sont également mis en cache en mémoire, mais doivent stocker des trucs dans une DB afin de pouvoir être retransmis entre des sessions de l'application.
Je vais me corriger à ce sujet, Marc Gravall a souligné que la première itération a une surcharge de buldation du modèle, de sorte que j'ai fait des tests en prenant la moyenne de 1 000 itérations de sérialisation et de désérialisation pour XML et Binary. J'ai essayé mes tests avec le V2 du cadre compact DLL d'abord, puis avec la DLL V3.5. Voici ce que j'ai eu, le temps est dans la MS:
.NET 2.0 ================================ XML ====== Binary === Serialization 1st Iteration 3236 5508 Deserialization 1st Iteration 1501 318 Serialization Average 9.826 5.525 Deserialization Average 5.525 0.771 .NET 3.5 ================================ XML ====== Binary === Serialization 1st Iteration 3307 5598 Deserialization 1st Iteration 1386 200 Serialization Average 10.923 5.605 Deserialization Average 5.605 0.279
XML est souvent lent à traiter et prend beaucoup d'espace. Il y a eu plusieurs tentatives différentes de s'attaquer à cela, et les plus populaires d'aujourd'hui semblent être de laisser tomber le lot dans un fichier gzip, comme avec le Convention d'emballage ouverte .
le W3C a montré que l'approche GZIP est inférieure à optimale, et elles et Divers autres groupes travaillent sur une meilleure sérialisation binaire appropriée pour le traitement et la compression rapides, pour la transmission .
La dépense principale de votre méthode est la génération réelle de la classe XMLSerializer. Créer le sérialisateur est un processus de consommation de temps que vous ne devez faire qu'une seule fois pour chaque type d'objet. Essayez de mettre en cache les sérialisateurs et voyez si cela améliore la performance du tout.
Suivre ce conseil, j'ai vu une grande amélioration de la performance dans mon application qui m'a permis de continuer à utiliser la sérialisation XML.
J'espère que cela aide.
J'allais suggérer d'utiliser le profileur des fourmis rouges, mais cela ne fonctionne pas avec le framework compact (recherche sur Google "Red-Gate FRONTS PROFILER Compact")