Estoy familiarizado con la optimización. Veo los programas de otras personas con un par de ojos diferentes. Aquí está mi opinión:
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.
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.
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".
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).
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?
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).