Comment savoir ce qui mach_msg_trap attend?

J'ai un profilage mon iPhone application sur la cible, et selon les Instruments de 65% du temps est passé dans mach_msg_trap.

J'ai un thread d'arrière-plan qui fonctionne toujours et envoyer les résultats au fil conducteur à l'aide de performSelectorOnMainThread:withObject:waitUntilDone:, environ toutes les 2 secondes. Je ne suis pas en attente jusqu'à ce que fait.

InformationsquelleAutor PeyloW | 2009-09-28
  1. 24

    Tourner mon application n'est pas en fait dépenser 65% de son temps dans la mach_msg_trap fonction. C'était une erreur de configuration dans les Instruments de ma part.

    L'Échantillonneur de l'outil par défaut Tous les exemples de Compte, cela permettra de mesurer tous les threads indépendamment de leur état.

    Au lieu de l'interrupteur à Échantillon en cours d'Exécution Temps qui permettra de tenir compte de la charge de travail réelle.
    Capture d'écran des Instruments http://developer.apple.com/library/mac/qa/qa2009/images/qa1619_running_sample_times.png

    • tous les liens sont rompus ici
    InformationsquelleAutor PeyloW
  2. 2

    Si vous n'êtes pas s'attendre à votre thread principal pour faire autre chose que d'attendre sur ce thread d'arrière-plan (ou l'attente de la saisie de l'utilisateur) il n'y a rien à être inquiète, votre demande n'a tout simplement rien à faire, la plupart du temps.

    Si vous attendons à ce que le thread principal pour être activement en faisant autre chose, veuillez mettre à jour votre question à la décrire. Dans ce cas, vous pouvez jeter un oeil à la gamme complète de piles d'appels à mach_msg_trap comme c'est souvent au fond d'une pile d'appel où le temps réel-gaspilleur est plus haut.

    • Je ne m'attends pas mon thread principal à faire beaucoup, à l'exception de recevoir la mise à jour et le rafraîchissement de l'écran une fois toutes les 2 secondes. Je dois cependant attendre mon thread d'arrière-plan à prendre chaque cycle d'horloge, de gauche plus de.
    • Je pense toujours qu'il peut être la peine de vérifier la pile au-dessus de mach_msg_trap pour vérifier votre hypothèse sur que le thread principal devrait être au ralenti.
    InformationsquelleAutor nall