Los ciclos inactivos ("no hacer nada") también se mostrarán como "(programa)" (puede perfilar esta página SO durante unos segundos y obtener el 100% de (programa)), así que esto no es un signo de algo malo en sí mismo.
La otra cosa es cuando realmente ve la aplicación rezagada. Entonces (programa) será contribuido por el código de enlaces V8 (y el código WebCore que invocan, que es esencialmente cualquier cosa: operaciones DOM/CSS, pintura, asignaciones de memoria y GC, lo que no). Si ese es el caso, usted puede grabar una línea de tiempo de su aplicación (cambie al panel Timeline en Herramientas del desarrollador y presione el botón Record en la barra de estado inferior, luego ejecute la aplicación por un tiempo). Verá muchos eventos internos con sus tiempos como barras horizontales . Verá reflows, recálculos de estilo, temporizadores disparados, eventos de GC y más (por cierto, las últimas versiones de Chromium tienen una mejor línea de tiempo de utilización del perfilador de memoria, por lo que también podrá controlar la memoria utilizada por ciertos factores internos).
Para diagnosticar problemas de memoria (asignaciones múltiples que implican múltiples ciclos completos de GC) puede usar el panel Profiles. Tome una instantánea de montón antes de que comience la parte intensiva de su código, y otra después de que este código se haya ejecutado durante un tiempo. Luego, compare los dos diagramas (el SELECTO correcto en la parte inferior) para ver qué asignaciones han tenido lugar, junto con su impacto de memoria.
Es posible que desee comprobar su javascript para cualquier bucle. Por lo general, cuando tienes ese tipo de uso es de algo que se ejecuta tan rápido como puede en un bucle. – Developer
Puede considerar cargar una captura de pantalla de generador de perfiles. – c69
Puede intentar depurar el navegador en sí ... http://www.mail-archive.com/[email protected]/msg06911.html Pero sospecho que sus puntos calientes están en DOM/Rendering/other (fileacces ? xhr?) código, y no en JS. – c69