Cómo mostrar el número de veces que se invocan funciones en el Analizador de time de instrumentos

He intentado todos los campos posibles pero no puedo encontrar el número de veces que se llaman funciones.

introduzca la descripción de la imagen aquí

Además, no obtengo Self y # Self . ¿Qué significan estos dos numbers?

Hay varias otras forms de lograr esto. Obviamente, uno es crear un contador estático y un NSLog que emite e incrementa un contador. Sin embargo, esto es intrusivo y encontré una forma de hacerlo con lldb.

  1. Establecer un punto de interrupción
  2. Ejecute el progtwig hasta que llegue al punto de interrupción la primera vez y anote el número de punto de interrupción en el lado derecho de la línea que golpee (por ejemplo, "Subprocess 1: punto de ruptura 7.1", anote el 7.1)
  3. Context, click el punto de interrupción y select "Editar punto de interrupción"
  4. Deje la condición en blanco y elija "Agregar acción"
  5. Elija "Comando depurador"
  6. En el cuadro de command, ingrese "breakpoint list 7.1" (usando el número de punto de interrupción para su punto de interrupción del paso 2). Creo que puedes usar "break de información" si estás usando gdb. introduzca la descripción de la imagen aquí
  7. Marque las opciones "Continuar automáticamente después de evaluar" Configuración del punto de interrupción
  8. Continuar

Ahora, en lugar de detenerse, llvm emitirá información sobre el punto de interrupción, incluida la cantidad de veces que se ha pasado.

En cuanto a la discusión entre Glenn y Mike en la respuesta anterior, describiré un problema de performance donde el conteo de ejecución de funciones fue útil: tuve una acción particular en mi aplicación donde el performance se degradó considerablemente con cada ejecución de la acción. El perfilador de time de Instrumentos mostró que cada vez que se ejecutaba la acción, una function particular tomaba el doble de time que la anterior, hasta que la aplicación se bloqueaba rápidamente si la acción se realizaba repetidamente. Con el recuento, pude determinar que con cada ejecución, la function se llamaba dos veces más veces que durante la ejecución anterior. Fue entonces bastante fácil search el motivo, que resultó ser que alguien estaba volviendo a registrarse para una notificación en NotificationCenter en cada ejecución de evento. Esto tuvo el efecto de duplicar el número de llamadas de controller de respuesta en cada ejecución y, por lo tanto, duplicar el "costo" de la function cada vez. Saber que se duplicaba porque se llamaba el doble de veces y no porque el performance estaba empeorando me hizo mirar la secuencia de llamadas en lugar de por razones que la function misma podría degradar con el time.

Si bien es interesante, saber el número de veces que se llama no tiene nada que ver con cuánto time se gasta en ellos. De qué se trata el Time Profiler. De hecho, ya que hace muestreo, no puede responder cuántas veces.

Parece que no puede usar Time Profiler para contar llamadas a funciones. Esta pregunta parece abordar posibles methods de conteo.

W / respecto a sí mismo y #self :

Self es "El número de veces que el símbolo se llama a sí mismo". de acuerdo con Apple Docs en el Time Profiler.

Por la forma en que aparecen los numbers, parece self la duración sumda de las muestras que tenían este símbolo en la parte inferior de su traza de stack. Eso haría:

  • # self : el número de muestras donde este símbolo estaba en la parte inferior de la traza de la stack
  • % self : el porcentaje de muestras de uno mismo en relación con el total de muestras del tree de llamadas que se muestra actualmente
    • (por ejemplo, #self / total samples ).

Entonces, esto no le dirá cuántas veces se llamó un método. Pero le daría una idea de cuánto time se gasta en un método o más bajo en el tree de llamadas.

NOTA: Sin embargo, tampoco estoy seguro acerca de los diversos significados de "yo". Me encantaría ver a alguien responder de manera autorizada. Llegamos aquí buscando eso …

SI su objective es averiguar qué necesita arreglar para hacer el progtwig lo más rápido posible,

El número de llamadas y la hora del auto pueden ser interesantes pero son irrelevantes.

Mire mi respuesta a esta pregunta , en particular los puntos 6 y 8.

EDITAR: Para aclarar el punto más adelante, suponga que la siguiente es la línea de time de ejecución del progtwig. Parte de ese time (en este caso, aproximadamente el 50%) se gasta en una actividad que se puede eliminar, si sabe de qué se trata, como E / S enterrada innecesariamente, llamadas excesivas a notifications new o desbordadas o datos "insignificantes" validation. Si se toma una muestra de time aleatorio, tiene un 50% de probabilidades de que ocurra en esa actividad, y un examen de la stack de llamadas y / o las variables del progtwig muestra que está haciendo algo que se puede eliminar. Luego, si se toman 10 de estas muestras, la actividad se verá en aproximadamente 5 de ellas, independientemente de si la actividad ocurre en algunos grandes trozos de time o muchos pequeños. La actividad puede ser unas pocas líneas de código en una function que hace algo innecesario, o puede ser algo mucho más generalizado. En cualquier caso, lo reconoce, lo corrige y obtiene aproximadamente un factor de 2 de aceleración. Los conteos de llamadas y la autocontrol no contribuyen en nada a este process.

introduzca la descripción de la imagen aquí