53 votes

Quelle empreinte la gestion des exceptions C ++ ajoute-t-elle

Cette question est importante, en particulier pour le développement embarqué. La gestion des exceptions ajoute quelques empreinte générée binaire de sortie. D'autre part, sans exceptions, les erreurs doivent être traitées d'une autre manière, ce qui exige plus de code, qui finalement augmente également la taille du binaire.

Je suis intéressé par vos expériences, en particulier:

  1. Qu'est-ce que la moyenne de l'empreinte ajouté par le compilateur pour la gestion des exceptions (si vous avez de telles mesures)?
  2. Est la gestion d'exception vraiment plus cher (beaucoup disent que, en termes de sortie binaire taille, que l'autre erreur de traitement de stratégies?
  3. Quelle erreur de manipulation de la stratégie suggérez-vous pour le développement embarqué?

Veuillez prendre mes questions uniquement à titre d'orientation. Toute contribution est la bienvenue.

35voto

bias Points 869

Lorsqu'une exception se produit , il y aura une surcharge de temps qui dépend de la façon dont vous mettez en œuvre votre gestion des exceptions. Mais, d'être anecdotique, la gravité d'un événement qui devrait provoquer une exception prendra autant de temps à la poignée à l'aide de toute autre méthode. Pourquoi ne pas utiliser le grand soutien de la langue de base de la méthode de traiter ces problèmes?

Le compilateur GNU C++ utilise le zéro–modèle de coût par défaut, c'est à dire il n'y a pas de temps de charge lorsque les exceptions ne se produisent pas.

Puisque l'information sur l'exception de code de traitement et les décalages d'objets locaux peut être calculé une fois au moment de la compilation, de telles informations peuvent être gardés dans un seul lieu associé à chaque fonction, mais pas dans chaque ARI. Vous essentiellement retirer exception de frais généraux de chaque ARI et d'éviter ainsi le temps de pousser sur la pile. Cette méthode est appelée à coût zéro modèle de gestion des exceptions, et l'optimisation du stockage mentionné plus tôt, est connu comme l'ombre de la pile. - Bruce Eckel, Penser en C++ Volume 2

La taille de la complexité de frais généraux n'est pas facilement quantifiable, mais Eckel états une moyenne de 5 et 15 pour cent. Cela dépendra de la taille de votre code de gestion des exceptions dans le rapport à la taille de votre code d'application. Si votre programme est petit, puis les exceptions seront d'une grande partie de la binaire. Si vous utilisez un coût zéro modèle que les exceptions prendra plus de place pour supprimer la surcharge de temps, donc si vous vous souciez de l'espace et pas le temps de ne pas utiliser de coût zéro de la compilation.

Mon avis est que la plupart des systèmes embarqués d'avoir beaucoup de mémoire au point que, si votre système possède un compilateur C++ vous avez suffisamment d'espace pour y inclure des exceptions. Le PC/104 ordinateur que mon projet utilise a plusieurs GO de mémoire secondaire, 512 MO de mémoire principale, donc pas de problème d'espace pour les exceptions, même si, de nos micorcontrollers sont programmé en C. Mon heuristique est "si il y a un grand compilateur C++ pour cela, utiliser des exceptions, sinon utilisez C".

6voto

Alex Points 2858

Je travaille dans un faible temps de latence de l'environnement. (sous 300 microsecondes pour ma demande dans la "chaîne" de production), la gestion des exceptions, dans mon expérience, ajoute 5 à 25% du temps d'exécution en fonction de la quantité que vous faites!

Nous ne se soucient généralement binaire ballonnement, mais si vous obtenez trop de ballonnement, alors vous thrash comme un fou, donc vous devez être prudent.

Il suffit de garder le binaire raisonnable (dépend de votre configuration).

Je fais assez vaste, le profilage de mes systèmes.
D'autres mauvaises domaines:

La journalisation

La persistance (nous n'avons tout simplement pas le faire, ou si nous le faisons c'est en parallèle)

4voto

dirkgently Points 56879

Je suppose que ça dépend du matériel et des outils de port pour cette plate-forme spécifique.

Je n'ai pas les chiffres. Toutefois, pour la plupart intégrés de développement, j'ai vu des gens de serrage deux choses (pour VxWorks/GCC de la chaîne d'):

  • Modèles
  • RTTI

La gestion des exceptions n'utilisent à la fois dans la plupart des cas, il existe une tendance à jeter ainsi.

Dans les cas où nous voulons vraiment pour se rapprocher du métal, setjmp/longjmp sont utilisés. *Notez que ce n'est pas la meilleure solution possible (ou très puissant) sans doute, mais alors c'est ce que nous utilisons.*

Vous pouvez exécuter des tests simples sur votre bureau avec les deux versions d'une analyse comparative de suite avec/sans exception, de manutention et d'obtenir les données que vous pouvez compter sur plus.

Une autre chose à propos de développement pour l'embarqué: les modèles sont à éviter comme la peste-ils causer trop de la météorisation. Exceptions étiquette de modèles et de RTTI comme l'a expliqué Johann Gerell dans les commentaires (je suppose que cela a été bien compris).

Encore une fois, c'est juste ce que nous faisons. Qu'est-ce que tous les downvoting?

4voto

Michael Points 96

Une chose à considérer: Si vous travaillez dans un environnement embarqué, vous voulez obtenir l'application la plus petite possible. Microsoft C Runtime ajoute tout à fait un peu de surcharge des programmes. En supprimant le runtime C comme une exigence, j'ai été en mesure d'obtenir un programme simple d'être un 2KB fichier exe au lieu de 70 quelque chose de kilo-octets du fichier, et c'est avec toutes les optimisations pour la taille activée.

Gestion des exceptions C++ nécessite la prise en charge du compilateur, qui est fourni par le C de l'exécution. Les détails sont enveloppées dans le mystère et ne sont pas documentés. En évitant les exceptions C++ j'ai pu couper de l'ensemble de la C runtime library.

Vous pourriez dire à juste lier dynamiquement, mais dans mon cas ce n'était pas pratique.

Une autre préoccupation est que les exceptions C++ besoin limité RTTI (runtime type d'information) au moins sur MSVC, ce qui signifie que les noms de type de votre les exceptions sont stockées dans le fichier exécutable. L'espace-sage, il n'est pas un problème, mais il "sent" la plus propre à moi de ne pas avoir cette information dans le fichier.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X