Si j'ai une application WPF et pour le débogage, il existe des messages affichés sur la console. Cela affectera-t-il que les performances de l'application lorsque sa application configurée en tant qu'application Windows et aucune console n'est affichée?
4 Réponses :
Un goulot d'étranglement implique que c'est le point le plus lent de votre code. Nous ne pouvons pas savoir que si nous savons tout ce que vous faites.
Y a-t-il un impact sur la performance, oui, probablement. Ça ne fait rien, ça fait quelque chose . Cela va-t-il suffire à être le goulot d'étranglement de votre programme, je doute fortement. Cela va-t-il suffire à avoir un impact notable, il est possible, mais peu probable. Tout dépend de ce que fait de votre programme d'autre, et combien vous écrivez à la console (il aurait besoin d'être beaucoup pour vous de commencer à remarquer le temps nécessaire.)
Comme mentionné dans les commentaires, vous pouvez utiliser débog.writeline plutôt que console.writeline afin que vous puissiez voir la sortie lors du débogage, mais lorsque vous compilez le Libération de la construction, il n'imprimera pas ces déclarations.
faire quelque chose prend toujours plus de temps que de ne rien faire.
L'acte de rédaction de texte à une console NULL ne devrait pas être une performance majeure, mais ce que vous passez en tant que paramètres, et dans quel volume, pourrait être.
Mesurez les performances réelles avec et sans votre sortie de console pour vous voir si votre modèle d'utilisation est dans vos tolérances acceptables.
debug.writeline () pourrait constituer un meilleur choix en fonction de vos besoins, car ceux-ci seront automatiquement exclus lorsque vous construisez à la libération.
Le véritable goulot d'étranglement de la console.writeline () est en réalité écrit à la console. Qui est vraiment cher, en particulier lorsque la console doit être défilée. Il existe également des frais généraux considérables dans le processus d'hébergement Visual Studio capturant la sortie lorsqu'il n'y a pas de console et l'affichage de la fenêtre de sortie.
dont aucun ne joue un rôle après avoir déployé votre application. Mais oui, tous les appels de méthode sont en cours de réalisation et les chaînes sont formatées, elle ne tombe que dans le bit-seau au dernier moment possible lorsque la fonction API Windows découvre qu'il n'y a pas de console.
Si votre application est acceptable PERF maintenant, lors de votre utilisation dans la construction de débogage, alors ne vous inquiétez pas pour cela. Si vous voyez moins que Stellar Perf dans la construction de libération sans débogueur et que vous pensez que cela pourrait être causé par console.writeline (), n'hésitez pas à rechercher + Remplacez-le à débogage.Print ().
essayer de construire et d'optimiser votre propre cadre de journalisation est rarement la meilleure approche.
Avez-vous regardé quelque chose comme Log4net? Vous pouvez configurer divers annexes, y compris la journalisation à la console. Vous pouvez également construire des appendeurs asynchronisés pour réduire réellement les frais généraux de journalisation.
Erick
Eh bien, pour le débogage, pourquoi ne pas utiliser debug.writeline? Il émet sur la fenêtre "sortie", mais peut être redirigé vers la fenêtre immédiate via des options Visual Studio si je ne me trompe pas.
Mesurez-le et vous saurez avec certitude :-)
Question similaire pour ASP.NET, ne garantira pas la réponse est la même: Stackoverflow.com/Questtions/137660/...