Leí en alguna parte que setInterval requiere mucha CPU. Creé un script que usa setInterval y supervisé el uso de la CPU pero no noté ningún cambio. Quiero saber si hay algo que eché de menos.¿Es intensivo el CPU setInterval?
Lo que hace el código es comprobar los cambios al hash en la URL (contenido después de #) cada 100 milisegundos y si ha cambiado, cargue una página usando AJAX. Si no ha cambiado, no pasa nada. Hubiera problemas con la CPU con eso.
No creo setInterval es de por sí va a causar problemas de rendimiento significativas. Sospecho que la reputación puede venir de una época anterior, cuando las CPU eran menos poderosas.
hay maneras en que puede mejorar el rendimiento, sin embargo, y es probable que sea prudente para hacerlas:
setInterval, en lugar de una cadena.No optimice prematuramente: no le haga la vida difícil cuando no haya ningún problema.
Una cosa, sin embargo, que puede hacer en su caso particular es utilizar el evento onhashchange, en lugar de tiempos de espera, en buscadores que lo admitan.
Gracias por el consejo. Todas las respuestas a este hilo han sido muy útiles, y les agradezco a todos por ello. Elegí esta respuesta porque onhashchange fue muy útil. – Ryuku
¡Vaya respuesta muy completa y concisa! ¡Gracias por los consejos! –
Yo votaría esto por el "No optimizo prematuramente" solo. Agradable y conciso, muy útil. – ghukill
No, setInterval no consume mucha CPU por sí solo. Si tiene muchos intervalos que se ejecutan en ciclos muy cortos (o una operación muy compleja que se ejecuta en un intervalo moderadamente largo), entonces que puede consumir fácilmente de la CPU, dependiendo de qué hacen exactamente sus intervalos y con qué frecuencia lo hacen eso.
No esperaría ver ningún problema con la comprobación de la URL cada 100 milisegundos en un intervalo, aunque personalmente aumentaría el intervalo a 250 milisegundos, simplemente porque no espero que la diferencia entre los dos sea notable para un usuario típico y porque, por lo general, trato de usar los intervalos de tiempo de espera más largos que creo que puedo salirse con la suya, particularmente para cosas que se espera que resulten en no operaciones la mayor parte del tiempo.
Preferiría decir que es todo lo contrario. Usar setTimeout y setInterval correctamente, puede reducir drásticamente el uso de la CPU de los navegadores. Por ejemplo, usar setTimeout en lugar de usar un bucle for o while no solo reducirá la intensidad del uso de la CPU, sino que también garantizará que el navegador tenga la oportunidad de actualizar la cola de la interfaz de usuario con más frecuencia. Por lo tanto, los procesos en ejecución no se congelarán y bloquearán la experiencia del usuario.
Pero en general, usar setInterval realmente me gusta mucho en su sitio puede ralentizar las cosas. 20 intervalos de ejecución simultáneos con trabajos más o menos pesados afectarán el espectáculo. Y de nuevo ... realmente puedes estropear cualquier parte Supongo que no es un problema de setInterval.
... y, por cierto, no es necesario comprobar el hash de esa manera. Hay eventos para eso:
onhashchange
se dispararán cuando haya un cambio en el hash.
window.addEventListener('hashchange', function(e) {
console.log('hash changed, yay!');
}, false);
Hay un poco de comercialización allí bajo el término "intensivo de la CPU". Lo que realmente significa es "más intensivo de CPU que algunas alternativas". No es "intensivo en CPU" ya que "utiliza una gran cantidad de potencia de CPU como lo haría un juego o un algoritmo de compresión".
Explicación:
Una vez que el navegador ha cedido el control se basa en una interrupción de el sistema operativo subyacente y el hardware de control para recibir y tema de la devolución de llamada de JavaScript. Tener duraciones más largas entre estas interrupciones permite que el hardware ingrese a estados de baja energía que disminuye significativamente el consumo de energía. De forma predeterminada, el sistema operativo Microsoft Windows y los procesadores basados en Intel utilizan resoluciones de 15.6ms para estas interrupciones (64 interrupciones por segundo). Esto permite que los procesadores basados en Intel ingresen a su estado de energía más bajo.Por esta razón, los desarrolladores web tienen tradicionalmente sólo sido capaz de lograr 64 devoluciones de llamada por segundo cuando se utiliza setTimeout (0) al utilizar navegadores HTML4 incluyendo ediciones anteriores de Internet Explorer y Mozilla Firefox.
lo largo de los últimos dos años los navegadores han tratado de aumentar el número de devoluciones de llamada por segundo que los desarrolladores de JavaScript pueden recibir a través de el setTimeout y setInterval de API cambiando el poder consciente la configuración del sistema de Windows y la prevención de hardware de la entrada de baja potencia estados. La especificación de HTML5 se ha ido al extremo de recomendando 250 devoluciones de llamada por segundo. Esta alta frecuencia puede resultar en un aumento del 40% en el consumo de energía, lo que afecta la vida de la batería, gastos de operación, y el medio ambiente. Además, este enfoque no aborda el problema de rendimiento central de la mejora de la eficacia y la programación de la CPU .
De http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
En su caso no habrá ningún problema. Pero si estás haciendo animaciones enormes en canvas o trabajando con webgl, entonces habrá algunos problemas con la CPU, así que para eso puedes usar requestAnimationFrame.
Consulte este enlace About requestAnimationFrame
tiempo Función> intervalo de tiempo es malo, no se puede saber Cuando hipo o CPU es lento y se acumula en la parte superior de las funciones en curso hasta que la PC se congela. Use settimeout o incluso mejor, process.nextick usando una devolución de llamada dentro de un settimeout.
realmente depende de la función que se llama y la cantidad de tiempo que especifique. Obviamente, llamar a una función cada 100 milisegundos que tenga 1000 líneas de longitud requerirá una gran cantidad de CPU. – Shaz
En Chrome, la función de intervalo solo se llama una vez por segundo si la pestaña está inactiva, por cierto. Por lo tanto, si su sitio web/aplicación no está activo, es ciertamente amigable para la CPU. – pimvdb
¿Es necesario sondear los cambios? ¿No puede simplemente agregar controladores de clics para todos sus anclajes? – davin