Por lo general, se considera que la microoptimización no vale la pena con la siguiente explicación: podría acelerar el programa en menos de un uno por ciento, pero a nadie le importa ese pequeño impulso, eso es un cambio demasiado pequeño como para notarlo.
Además, puede haber algún controlador de eventos que se dispare mil veces por segundo y salga muy rápido, antes de que se vuelva a disparar. A nadie le importa lo rápido que sea, no se puede notar que sea más rápido, porque ya "es tan rápido como se puede observar".
Sin embargo, en dispositivos móviles, el consumo de energía es un factor importante. El mismo controlador de eventos optimizado para funcionar un diez por ciento más rápido conducirá a una menor consumo de energía y una mayor duración de la batería y un dispositivo operativo más largo.
¿Cuán preciso es el último juicio sobre los dispositivos móviles? ¿Hay ejemplos de la vida real que lo confirmen o refuten?
fuente
Respuestas:
Vale la pena si las mediciones dicen que vale la pena. Para dispositivos móviles y supercomputadoras.
EDITAR: poco fuera del tema, pero sobre su ejemplo. Si el evento se desencadena demasiadas veces, entonces tienes un problema de concepción, y resolver ese problema de concepción es el verdadero negocio. No lo hace menos visible por microoptimización.
Puede realizar una prueba en la devolución de llamada, por ejemplo, para descartar llamadas demasiado frecuentes o reelaborar la forma en que se llama la devolución de llamada.
En general, es una mala práctica adjuntar la devolución de llamada a «eventos continuos». Con eso, me refiero a los eventos que no se activan una vez y luego se hacen, pero que se activan con acciones que duran con el tiempo.
Desplazarse por una página o un control deslizante, por ejemplo, son eventos continuos.
Nunca se sabe cuántas veces se activarán esos eventos. Si se activan lo suficientemente rápido, su aplicación se vuelve lenta, y si se activan demasiadas veces, terminará con una gran carga de CPU por nada, lo que podría hacer que su aplicación también sea lenta.
fuente
Es tan preciso como las mediciones reales en el dispositivo real que realmente indican que la optimización real realmente ayudará.
Las suposiciones y juicios no tienen valor.
Las medidas tienen valor.
Toda optimización (incluida la "microoptimización", sea lo que sea) es una pérdida de tiempo hasta que haya una medición real que indique un problema real en el que el código no cumpla con algún requisito (velocidad, memoria, potencia o latencia de red o lo que sea )
fuente
(Asumir que la velocidad es su problema principal). Todos tienen razón.
Excepto: la medición no le dirá qué optimizar.
La medición le indicará que necesita optimizar.
La medición le indicará cuánto ahorró cuando optimizó.
La medición no le dirá qué optimizar.
Esta técnica le dirá qué optimizar.
fuente
Estoy familiarizado con la optimización. Veo los programas de otras personas con un par de ojos diferentes. Aquí está mi opinión:
Lo curioso es que uno de esos cambios conduce al 99%. Diez de estos cambios hacen que el programa sea notablemente más rápido. Para muchos ingenieros, los cambios en su enfoque de escribir un programa pueden hacer que un programa se ejecute varias veces más rápido. Simplemente estar al tanto de la eficiencia y escribir de esa manera puede hacer que su programa sea varias veces más rápido sin mucho trabajo adicional. tales ganancias no son micro optimizaciones, en mi opinión.
nota: nunca estoy sugiriendo optimizaciones contextuales que corten las esquinas en esta discusión.
y es probable que ya esté haciendo más trabajo del necesario, ya que 1 kHz es mucho más alto de lo que requieren muchos casos. ¿Cuál es la fuente de este controlador de eventos y cuáles son sus efectos? si se trata simplemente de actualizar la interfaz de usuario y los eventos se pueden recopilar y fusionar, entonces el envío de 1 kHz es ciertamente excesivo (mucho más del 1%, más como 25x). para un sistema que tiene múltiples fuentes y se transmite en serie, entonces 1 kHz puede no ser lo suficientemente rápido (por ejemplo, MIDI).
Según los programas que he visto, no hay muchas personas considerando (o preocupadas) tales optimizaciones, a pesar de que cambiar su enfoque para escribir programas puede producir ganancias increíbles (> 10 veces o mucho más rápido). muchos de los que he visto (en el lado del desarrollo de aplicaciones) simplemente escriben y luego adoptan un enfoque de arriba hacia abajo o "granizo" cuando (/ si) los problemas de rendimiento los alcanzan. Del mismo modo, muchos ni siquiera se tomarán el tiempo para perfilar hasta tal ocurrencia. para entonces, el ruido de tantas ineficiencias compuestas hace que sea muy difícil obtener información útil de un generador de perfiles. ejemplos del enfoque de granizo sería optimizar las áreas equivocadas (con o sin buscar áreas problemáticas), o simplemente arrojar más núcleos en las áreas problemáticas; Esto sucede en lugar de corregir las ineficiencias existentes.
Para el programa existente típico (entre los programas móviles que he visto), la optimización no era una gran preocupación cuando se escribe. por lo tanto, "sí" valen (en el caso típico) el tiempo, siempre que esté en el presupuesto y sea una prioridad. en ese caso, esos diez cambios que hacen que el programa sea notablemente más rápido probablemente se puedan realizar en unas pocas horas y en menos de un día.
"escribir perezosamente y perfilar en retrospectiva" ya que la única acción para mejorar un programa es una idea terrible: tomarse el tiempo para aprender a escribir un programa eficiente (como está escrito, no pegándolo al final) es el superior enfoque (imo); use los algoritmos correctos, prohíba las copias innecesarias, las asignaciones, los cálculos (+ muchas, muchas otras categorías). por supuesto, analizar el rendimiento en retrospectiva tiene sus ventajas, pero si escribe el programa para que sea eficiente desde el principio, tendrá un nivel completamente nuevo de eficiencia porque aprende mucho y considera y evalúa la ejecución desde múltiples perspectivas.
La otra cosa es que los programas deben (a menudo) escribirse para su reutilización, un programa mal escrito introducirá cambios que pueden romper los programas de los clientes cuando se eliminan las ineficiencias (o simplemente seguir siendo ineficientes para evitar romper los programas existentes).
Una gran ventaja de considerarlo cuando escribe es que tiene una idea muy clara de cómo funcionará el programa (aunque no es una imagen completa), puede usar esta información para ayudar en el diseño de las interfaces y cómo almacena sus datos . la verdad es que un ingeniero puede implementar algo que es varias (por ejemplo,> 10 veces) más rápido que las soluciones estándar de "talla única" que se proporcionan con el sistema operativo.
Finalmente, también vale la pena más allá de los dispositivos móviles. Hay muchos programas ineficientes, escritos con la mentalidad de que el hardware será más rápido en dos años (razón frecuente, ¡incluso para programas escritos hoy!). Si bien eso no es incorrecto , es demasiado optimista. también, la paralelización tiene un propósito, pero es la "solución predeterminada" incorrecta para muchos programas. Muchos de estos programas existentes pueden mejorarse mejor eliminando primero las ineficiencias existentes.
entonces ... típicamente hay una tonelada de esos casos del 1%, 2%, 7% (y mucho peor) en el mundo real. corregirlos o (más importante) no escribirlos / exponerlos en primer lugar puede proporcionar grandes beneficios. Muchos de esos casos pueden localizarse y corregirse fácilmente (siempre que el ingeniero tenga experiencia con esto). Sin embargo, puede ser realmente un dolor corregir y volver a probar después del hecho. si un programa es óptimo, idealmente se escribirá de esa manera desde el principio.
Como usuario final, es irritante esperar continuamente programas lentos y lanzar el doble de hardware a los problemas creados por programas lentos / ineficientes: P: "¿qué va a hacer ahora que tiene el doble de núcleos y el doble de memoria?" R: "recupere la capacidad de respuesta y la productividad que tenía antes de actualizar mi software, eso es todo". bastante desconsiderado del desarrollador (en mi humilde opinión).
fuente
La razón por la que no debería molestarse con las micro optimizaciones es que son micro optimizaciones. Debería mirar la imagen más grande y, en lugar de perder el tiempo en micro optimizaciones, encontrar razones para mejoras reales .
Mi regla general es que cualquier código escrito sin tener en cuenta la velocidad, pero tampoco totalmente estúpido, puede hacerse diez veces más rápido con mucho esfuerzo. El 10% a través de micro optimizaciones no es algo con lo que me molestaría. Estoy seguro de que puede ahorrar mucho más que eso, con menos esfuerzo.
Por otro lado, en los productos comerciales en los últimos años, la "optimización" para mí consistió principalmente en encontrar código que perdiera el tiempo y no desperdiciarlo. Más falta de pesimismo que optimización.
(Por otro lado, algunas personas piensan que la optimización prematura es mala, por lo que si hay una forma de A para hacer algo y una forma B que es menos eficiente, elegirán B porque A es "optimización prematura" Algunas personas son simplemente estúpidas).
fuente