Podría estar sesgado al trabajar en áreas muy críticas para el rendimiento, como el procesamiento de imágenes y el trazado de rayos, pero aún así diría que optimice "lo más tarde posible" . No importa cuán críticos sean sus requisitos de rendimiento, siempre hay mucha más información y claridad en retrospectiva, después de medir, que por adelantado, lo que significa que incluso las optimizaciones más efectivas se aplican más tarde después de obtener dicho conocimiento.
Casos peculiares
Pero a veces "lo más tarde posible" todavía es bastante temprano en algunos casos peculiares. Si hablamos de procesadores sin conexión, por ejemplo, las estructuras de datos y las técnicas que utiliza para lograr el rendimiento realmente se filtran en el diseño del usuario final. Esto puede sonar repugnante, pero el campo es tan avanzado y tan crítico para el rendimiento que los usuarios aceptan los controles del usuario final específicos de las técnicas de optimización aplicables a un rastreador de rayos en particular (por ejemplo, almacenamiento en caché de irradiancia o mapeo de fotones), ya que algunos de ellos se utilizan a las horas de espera para que se renderice una imagen, y otros están acostumbrados a repartir enormes sumas de dinero para alquilar o poseer una granja de renderizado con máquinas dedicadas al renderizado. Hay una reducción masiva en tiempo y dinero para esos usuarios si un renderizador fuera de línea competitivo puede ofrecer una reducción no trivial en el tiempo dedicado a la representación. Este es un tipo de área donde una reducción del 5% en el tiempo realmente emociona a los usuarios.
En casos tan peculiares, no puede simplemente elegir una técnica de renderizado de manera involuntaria y esperar optimizarla más adelante, ya que todo el diseño, incluido el diseño del usuario final, gira en torno a las estructuras de datos y los algoritmos que utiliza. No necesariamente puede simplemente ir con lo que funcionó bien para otras personas, ya que aquí, usted, como individuo, y sus fortalezas y debilidades particulares, tienen un gran factor para ofrecer una solución competitiva. La mentalidad y la sensibilidad del desarrollador principal detrás de Arnold son diferentes de las que trabajan en VRay que usaron un enfoque muy diferente; no necesariamente pueden intercambiar lugares / técnicas y hacer el mejor trabajo (a pesar de que ambos son líderes industriales). Tienes que experimentar y crear prototipos y puntos de referencia y encontrar lo que ' eres particularmente bueno en hacerlo dada la infinita variedad de técnicas de vanguardia que existen si esperas enviar algo competitivo que realmente se venda. Entonces, en este caso peculiar, las inquietudes de rendimiento se mueven hacia adelante como tal vez la preocupación más importante incluso antes de comenzar el desarrollo.
Aún así, eso no es necesariamente una violación de la optimización "lo más tarde posible" , es simplemente "lo más tarde posible" es bastante temprano en estos casos extremos y peculiares. Averiguar cuándo y qué no necesita problemas de rendimiento tan tempranos, si acaso, es probablemente el principal desafío para el desarrollador. Lo que no se debe optimizar podría ser una de las cosas más valiosas para aprender y seguir aprendiendo en la carrera de un desarrollador, ya que no puede encontrar escasez de desarrolladores ingenuos que quieran optimizar todo (y desafortunadamente incluso algunos veteranos que lograron mantener su trabajo de alguna manera a pesar de su contraproductividad).
Lo más tarde posible
Quizás la parte más difícil es tratar de entender lo que significa. Todavía estoy aprendiendo y he estado programando durante casi tres décadas. Pero especialmente ahora en mi tercera década, estoy empezando a darme cuenta de que no es tan difícil. No es ciencia espacial, si te enfocas más en el diseño que en la implementación. Mientras más diseños dejen espacio para respirar para optimizaciones apropiadas más tarde sin cambios en el diseño, más tarde podrá optimizar. Y cada vez más productividad he ganado buscando tales diseños que me brinden ese espacio para respirar.
Diseñe qué ofrece sala de respiración para optimizar más tarde
Estos tipos de diseños en realidad no son tan difíciles de lograr en la mayoría de los casos si podemos aplicar algo de "sentido común". Como historia personal, me interesan las artes visuales como pasatiempo (creo que es de alguna manera útil programar software para que los artistas sean algo como yo mismo para comprender sus necesidades y hablar su idioma), y pasé un tiempo a principios de la década de 2000 usando los applets de Oekaki en línea como una forma rápida de garabatear y compartir mi trabajo y conectarme con otros artistas.
En particular, mi sitio y applet favoritos estaban plagados de fallas de rendimiento (cualquier tamaño de pincel no trivial se ralentizaría), pero tenía una comunidad muy agradable. Para solucionar los problemas de rendimiento, utilicé pequeños pinceles de 1 o 2 píxeles y garabateé mi trabajo así:
Mientras tanto, seguía dando al autor de las sugerencias de software para mejorar el rendimiento, y se dio cuenta de que mis sugerencias eran de naturaleza particularmente técnica hablando de optimizaciones de memoria y algoritmos, etc. Entonces él realmente preguntó si yo era programador y yo dije que sí y me invitó a trabajar en el código fuente.
Así que miré el código fuente, lo ejecuté, lo perfilé, y para mi horror, él había diseñado el software en torno al concepto de una "interfaz de píxeles abstractos" IPixel, que terminó siendo la causa raíz detrás de los principales puntos críticos para todo lo dinámico. asignaciones y despacho para cada píxel de cada imagen. Sin embargo, no había una forma práctica de optimizar eso sin reconsiderar el diseño de todo el software porque el diseño lo había atrapado en una esquina donde no hay mucho más allá de las micro optimizaciones más triviales cuando nuestras abstracciones funcionan al nivel granular de un solo píxel abstracto. y todo depende de este píxel abstracto.
Creo que es una violación del "sentido común", pero obviamente no fue un sentido común para el desarrollador. Pero es como no abstraer las cosas a un nivel tan granular donde incluso los casos de uso más básicos serán instanciados por millones, como con píxeles, partículas o pequeñas unidades en una simulación de ejército descomunal. Favorezca el IImage(puede manejar todos los formatos de imagen / píxel que necesita en ese nivel agregado más voluminoso) o IParticleSystemhacia IPixelo IParticle, y luego puede colocar las implementaciones más básicas y rápidas de escribir y fáciles de entender detrás de tales interfaces y tenga todo el espacio de respiración que necesitará para optimizar más adelante sin tener que reconsiderar todo el diseño del software.
Y ese es el objetivo tal como lo veo en estos días. Excluyendo los casos peculiares como los renderizadores sin conexión anteriores, diseñe con suficiente espacio para respirar para optimizar lo más tarde posible, con tanta información retrospectiva como sea posible (incluidas las mediciones), y aplique las optimizaciones necesarias lo más tarde posible.
Por supuesto, no estoy sugiriendo necesariamente comenzar usando algoritmos de complejidad cuadrática en entradas que alcanzan fácilmente un tamaño no trivial en casos comunes de usuarios finales. ¿Quién hace eso de todos modos? Pero ni siquiera creo que sea un gran problema si la implementación es fácil de cambiar más tarde. Eso todavía no es un grave error si no tiene que reconsiderar ningún diseño.