2010-08-24 15 views
5

Je travaille sur une application mobile Qt assez standard (écrite en C++, ciblée sur les appareils Symbian), et je trouve parfois que lorsque l'application est fermée (par exemple via un appel à QApplication :: quit), le dernier destructeur de l'application peut prendre beaucoup de temps à retourner (30 secondes plus). Par cela je veux dire, toutes les opérations de nettoyage dans le destructeur ont terminé (rapidement, tout bien dans une seconde) et nous avons atteint le point où l'exécution quitte le destructeur et retourne au code qui l'a implicitement appelé (ie lorsque nous supprimons L'object). Évidemment, à ce moment-là, je m'attendrais à ce que l'exécution revienne juste après l'appel pour supprimer l'objet, presque instantanément, mais comme je le dis parfois, cela prend un âge!Qt destructeur de C++ prend beaucoup de temps à retourner

Cette longue fermeture se produit à la fois dans les versions de débogage et de publication, avec la journalisation activée ou désactivée, donc je ne pense pas que ce soit un facteur ici. Quand nous arrivons à la fin du destructeur, je suis quasiment certain qu'aucun descripteurs de fichiers ne sont laissés ouverts, ou aucune autre ressource ouverte (connexions réseau etc ...) ... même si, sûrement, cela ne poserait pas de problème sur quitter le destructeur (?).

Il s'agit de la suppression de l'objet QMainWindow de l'application. Actuellement l'appel à faire ceci est dans un slot connecté à QApplication :: aboutToQuit, bien que j'ai essayé de supprimer cet objet aussi dans la fonction "main" des applications.

La longueur du délai que nous expérimentons semble proportionnelle à la quantité d'activité dans l'application avant de sortir. Ce genre de me fait penser que les fuites de mémoire peuvent être un problème ici, cependant nous ne sommes pas au courant (ne veut pas dire ne sont pas bien sûr), et aussi je n'ai jamais vu ce comportement avant avec fuite Mémoire.

Quelqu'un a-t-il des idées sur ce qui pourrait se passer ici?

Vive

+0

Est-ce que vous rencontrez ce problème si vous utilisez également un débogueur? Pouvez-vous isoler la (les) ligne (s) de code qui prend si longtemps? –

+0

Oui, je vois cela dans le débogueur aussi. En ce qui concerne l'isolation des segments de code qui prennent trop de temps, le problème est que le retard se produit lors du retour du destructeur lui-même. Ainsi, la dernière ligne du destructeur est terminée, nous sortons du destructeur et c'est à ce moment que le retard se produit. Je crois que le framework Qt fait quelque chose à ce moment-là qui cause le retard, même si je ne sais pas encore quoi. – busta83

Répondre

4

Si votre destructor finale est pour une classe que hérite QObject alors la destructor QObject sera appelé immédiatement après la destructor de votre objet final. On peut supposer que cet objet est la racine d'un arbre d'objets éventuellement important qui déclenchera un certain nombre d'actions, y compris l'appel du destructeur de tous les QObjects enfants. Puisque vous indiquez que le problème est lié à la quantité d'activité, un très grand nombre d'enfants est probablement ajouté à l'arborescence d'objets supprimée à ce moment, peut-être plus que ce que vous aviez prévu. Au lieu d'ajouter tous les objets à un arbre géant à supprimer tout à la fois. Identifiez les objets souvent créés qui n'ont pas besoin de persister pendant toute l'exécution. Au lieu de créer ces objets avec un parent, commencez une nouvelle arborescence qui peut être supprimée plus tôt (parent = 0). Regardez QObject :: deleteLater() qui attendra jusqu'à ce qu'il n'y ait aucune interaction de l'utilisateur pour supprimer les objets dans ces arbres indépendants.

+0

J'ai commencé à supprimer certains des rôles parentaux et à utiliser deleteLater à la place, et je constate des améliorations notables dans le temps de destruction. Excellente substance, merci! – busta83