¿Fomentar un período de tiempo en el que todos puedan probar alguna idea para hacer que el software funcione más rápido?

A veces, los trucos de rendimiento del software se encuentran a partir de una búsqueda metodológica y exhaustiva. A veces se requiere un pensamiento divergente y coraje para probar ideas locas. A veces, una idea es solo el comienzo que debe seguirse con mucho trabajo duro.

¿Cómo fomentar un período de tiempo en el que todos puedan probar diferentes ideas para mejorar el rendimiento del software en el que estamos trabajando? Todos en el equipo tienen al menos varios meses de experiencia con el software y son muy buenos en eso.

¿Está de acuerdo en que el pensamiento divergente ayudará a encontrar formas de mejorar el rendimiento del software? ¿Por qué? Por qué no?

¿Qué técnicas nos permitirán probar rápidamente una idea de optimización? ¿Es necesaria una velocidad de codificación rápida para obtener buenos resultados de la prueba?

Finalmente, ¿cuánto "tiempo" debe asignarse para garantizar buenos resultados sin crear la posibilidad de aflojar?

¿Es necesaria la experimentación para demostrar que existe "una forma más rápida de hacer algo"? (Agregado 2011-06-07)

Relacionado:

• ¿Cuáles son sus estrategias para mejorar el nivel de su equipo de una manera inteligente?
• ¿Cuándo se vuelven malos los hacks de código?

( Solo para fines de recompensa -2011/06/07, el tamaño del equipo es de 2-4 desarrolladores, sin control de calidad dedicado. Todos los códigos, pruebas unitarias y pruebas de rendimiento realizadas por desarrolladores. Debido a la naturaleza del proyecto, el resultado del generador de perfiles es útil para mostrar tiempo de ejecución proporcional incluso si no revela un solo cuello de botella).

Su mejor opción es identificar los puntos de acceso con un generador de perfiles y, como equipo, discutir cómo solucionar los puntos de acceso.

Debe ser capaz de medir y documentar la mejora (por lo que no es solo una suposición descabellada) y hacerlo en equipo garantiza que las personas sepan qué se está arreglando y cómo.

Hacer que los programadores pirateen salvajemente la base de código probando ideas significa que no tienes control de lo que está sucediendo y de si funciona.

Los programadores tienden a ser inteligentes y creativos (ya que estos son requisitos previos para ser buenos en la programación), por lo que siempre es bueno dejar que prueben una amplia gama de ideas al tratar de resolver problemas. Sin embargo, hay dos cosas que es importante recordar al intentar mejorar el rendimiento (supongo que con "rendimiento" se refiere a reducir la velocidad de ejecución):

• Las optimizaciones algorítmicas tienden a funcionar mucho mejor que cualquier otra cosa. Como ejemplo trivial, lo que sea que haga a su implementación de bubbleort, con números suficientes, una implementación extremadamente lenta de quicksort eventualmente será más rápida.
• Hacer cualquier cosa relacionada con el rendimiento es completamente absurdo a menos que mida (perfil) y base lo que haga en los resultados.

Mi punto principal es que es importante asegurarse de estar en la misma página con todos con respecto a estas cosas antes de comenzar un período de experimentación salvaje . Siempre es una lástima descubrir después que sus compañeros de trabajo menos experimentados estaban intentando cosas que nunca podrían funcionar (y podría haberles dicho eso por adelantado).

Lamentablemente, no puedo hablar por experiencia. Pero escuché que Atlassian tiene un solo día en el que a los empleados se les permitía hacer lo suyo, lo que quisieran, y presentar sus ideas en una especie de ambiente de fiesta. Al parecer resultó bien para ellos. Pero tendría que estar de acuerdo con Andersen y decir que cuando se trata de rendimiento, las ideas creativas y listas para usar son menos importantes que el perfil de los procesos que toman más tiempo. Tal vez una vez que haya perfilado su sistema, podría darles a todos un día para tener ideas sobre cómo ayudar a acelerar secciones importantes del proceso. Después de que presenten sus ideas, puede elegir cuáles probar.

Una práctica exitosa que hicimos en algunos de mis equipos anteriores fue tener el concepto de inmersiones profundas. Algunas personas se reunirían en una sala de conferencias, determinarían un escenario de usuario y simplemente comenzarían a recorrer el código o mirar los registros del generador de perfiles. ¡En algunos casos, los datos mostraron claramente cuellos de botella que nos permitieron convencer a los escépticos de que realmente había problemas de rendimiento en su propio código! Para que esto sea exitoso, seguimos algunos principios clave que seguimos:

1. Intente centrarse en escenarios críticos o rutas de código donde se sospechen cuellos de botella. No pierdas el tiempo optimizando cosas que no necesitan ser optimizadas (si no está roto ...)
2. Mantenga al grupo pequeño y centrado en las personas que mejor conocen el código. No olvide incluir al evaluador y al administrador del programa de la función: tienen conocimientos clave y pueden beneficiarse de participar o recopilar información sobre cómo pueden probar mejor.
3. Comience la sesión haciendo que el propietario del área proporcione un diagrama de nivel de bloque arquitectónico de alto nivel y una visión general del área. ¿Cuáles son los componentes clave? Describa brevemente lo que hacen. Te sorprenderá cuántas veces el diagrama de bloques no refleja la realidad una vez que profundizamos en el código. (Cita real: "No sabía que aún usábamos ese componente. ¡Pensé que lo habíamos eliminado hace años!")
4. Espere encontrar errores funcionales, así como problemas de rendimiento. Eso es bueno. Además, espere que, a veces, no encuentre nada significativo. Eso también puede ser algo bueno.
5. Espere tener varias sesiones largas. Estas son reuniones de trabajo. Póngase cómodo y trabaje en ello. Se puede hacer mucho más cuando todos pueden colaborar durante largos períodos.
6. Toma notas, buenas notas. Si utiliza una base de datos de seguimiento de defectos, considere abrir los problemas de inmediato para realizar un seguimiento, incluso si son de baja prioridad.

Evite que todo el equipo participe en un "Performance Push". Estos generalmente no tienen los resultados que la gerencia espera por las razones que Thorbjørn Ravn Andersen mencionó en otra respuesta. Obtendrá grandes ganancias en algunas áreas, regresiones en otras áreas donde las personas no están familiarizadas, y es difícil predecir / rastrear cuántas ganancias debería obtener para decir "ha terminado". Esa es una conversación desafiante para tener con la gerencia.

La razón por la que podría necesitar mejorar la velocidad de su software es si algo en él es notablemente lento. Si ese no es el caso, entonces la optimización es una pérdida de tiempo. Pero si algo es lento, entonces haz la tarea.

... Y para hacer la tarea, hay dos pasos en este orden:

1. Vea si la función que realiza la tarea se escribe de manera eficiente. ¿Tiene un algoritmo bueno o malo? ¿Está accediendo a una base de datos de manera eficiente? ¿Se repite 100 veces cuando una vez puede hacerlo? A menudo, una simple inspección del código puede encontrar el único obstáculo y no solo solucionarlo, sino que también lo convierte en un mejor programador al mismo tiempo.

2. No pase más de una hora más o menos en el número 1. Si no puede encontrar el problema en una hora, utilice un generador de perfiles para encontrar el lugar en cuestión. Una vez que conozca el punto problemático, puede volver al número 1 y volver a hacerlo, presionando para encontrar la mejor manera de mejorar el código que ha identificado.

En general (**) no obtienes un mejor rendimiento mediante la experimentación.

Lo consigues

• Saber cómo hacer un diseño simple y eficiente para empezar. Si se equivoca esta parte, la experimentación no hará mucha diferencia. Por ejemplo, saber cómo saber cuándo usar un generador de código es un enfoque de diseño ganador.

• Saber cómo ajustar el software localizando las actividades que son a) costosas en porcentaje, yb) reemplazables por algo mejor. Todo el mundo sabe que debes "usar un generador de perfiles", pero eso no es suficiente.

Verifique esta respuesta a su otra pregunta.

** Las excepciones pueden ser un código estricto que depende del hardware, como la representación gráfica, la canalización del procesador o el comportamiento de CUDA, o experimentar con protocolos de red o DB, donde solo necesita familiarizarse con la mejor manera de usarlo.

AGREGADO: Hay algo que muchos programadores de sistemas grandes encuentran sorprendente. Es que en grandes programas perfectamente bien construidos, puede haber problemas de rendimiento grandes e invisibles , y los perfiladores no pueden encontrarlos porque no están localizados en las rutinas. Forman parte de la estructura general del programa, a pesar de que el programa se puede realizar con el mejor estilo.

Solo para dar un ejemplo concreto, aquí hay un programa con código fuente (en C ++) que hace un trabajo. Está destilada de un programa C real en el que trabajé.

Hace lo que estaba destinado a hacer, pero ¿qué fracción de su tiempo no es realmente necesario? ¿Cuánto se puede acelerar?

Bueno, en la primera versión del programa, algo perfectamente razonable y no local (invisible para un generador de perfiles) estaba tomando el 33.3% del tiempo. Cuando se reemplazó, se ahorró ese tiempo, y esa fue la segunda versión del programa.

En la segunda versión del programa, algo más (invisible para cualquier generador de perfiles) que podía eliminarse tomaba el 16,7% del tiempo. Eliminarlo condujo a la versión 3.

En la versión 3, se eliminó el 13%. De lo que quedaba, se eliminó el 66%. ¡De lo que quedó después de eso, se eliminó el 61%!

Luego, finalmente, de lo que quedó después de eso, ¡se eliminó el 98%!

Entonces, ¿cuál es el panorama general? De cada 1000 ciclos gastados por el programa original, ¿cuántos fueron eliminados? 998!

Cada programa es diferente, pero cada programa grande, en mi experiencia, tiene una serie de problemas que los perfiladores no encontrarán, que el muestreo manual sí lo hará, y que, si los programadores realmente buscan el máximo rendimiento, pueden eliminarse para grandes aceleraciones.