performance - unity - ¿Siempre tengo que pensar en el rendimiento?

wpo calidad (21)

¿Cuándo tengo que pensar en el rendimiento y cuándo no?

Puedes pensar en el rendimiento, siempre que evites que los ciclos piensen sobre la corrección. :-)

La mayoría de las veces, sin embargo, su pensamiento será "el rendimiento de este bit no importa: tampoco, porque el rendimiento de toda la aplicación sigue siendo correcto incluso con este bit, o porque el costo de este bit es insignificante o infinitamente comparado con el costo de ese otro bit ".

Vengo de un mundo de DBA y el rendimiento siempre ha sido una obsesión. Estoy recurriendo al desarrollo y siempre pienso en el rendimiento, constantemente, todo el tiempo.

Leer en SO a veces parece que el rendimiento no importa. Por ejemplo, para los evangelistas en Hibernate (o cualquier otro ORM).

Como desarrollador, ¿cuándo tengo que pensar en el rendimiento y cuándo no?

Cuando lo hace?

No en serio. Hay algunas aplicaciones que nunca tendrán suficientes usuarios para garantizar más que los índices básicos y las relaciones clave en la base de datos. No requerirán sintonización de los bucles internos del código. Aplicaciones de tamaño de grupo de trabajo, por ejemplo.

A medida que las cosas escalan, también lo hace la demanda de rutas optimizadas, tanto en código como en acceso a datos y comunicación. Si está trabajando en hardware limitado (sistemas integrados), se preocupa mucho por el rendimiento. Pero hay muchas, muchas aplicaciones que nunca verán suficientes usuarios para hacer que los recursos del sistema ni siquiera noten que usted está allí.

En esos casos, todo ese trabajo extra es un desperdicio de dinero y esfuerzo . En algunos casos, su especificación deja en claro que necesita ese esfuerzo adicional. En algunos casos, deja en claro que nunca lo harás .

Debe optimizar el rendimiento después de que haya creado su aplicación y solo si tiene pruebas de dónde están sus cuellos de botella. (Por ejemplo, mediante creación de perfiles) Tal vez descubra que no es necesario optimizar, especialmente porque el compilador suele ser mucho mejor que usted.

En términos generales, obsesionarse con el rendimiento u optimización es la ruta a mucho mal en el desarrollo de software. Por lo general, solo alrededor del 5% (¡o menos!) De su código tiene algún impacto en el rendimiento del sistema en general. Sus objetivos principales, en primer lugar, como desarrollador de software en la mayoría de los proyectos, es lograr una funcionalidad correcta y confiable, y también, por supuesto, la capacidad de mantenimiento del sistema. Luego, una vez implementado y funcionando correctamente, usted evalúa el desempeño, descubre dónde están los cuellos de botella y los optimiza en consecuencia para alcanzar sus objetivos generales.

Una advertencia : Hacer evaluaciones de tipo O (n) de los enfoques que lleva a las cosas son razonables para considerar de antemano como parte del diseño original del sistema y la selección de algoritmos, etc. solo para sentirse seguro de que el rendimiento será "en el parque de béisbol" . Pero más allá de eso, la mayoría de los intentos de optimizar las cosas antes de medir realmente dónde están los cuellos de botella darán como resultado la optimización de las cosas que no importan y generalmente hacen que las cosas sean menos sostenibles, más difíciles de entender, etc.

La cita de Knuth ("Debemos olvidarnos de las pequeñas eficiencias, digamos aproximadamente el 97% del tiempo: la optimización prematura es la raíz de todo mal") probablemente se aplique.

Cuando conduce su automóvil, ¿constantemente y conscientemente revisa qué tan cerca está su auto de la acera? Si tienes suficiente experiencia conduciendo un automóvil, aprendes a saber dónde están sus bordes y aproximadamente cómo conducir y estacionar sin tocar algo cercano.

El tipo análogo de intuición / experiencia para el rendimiento de la programación es importante para ganar a través de la prueba / error y las preguntas, pero no debería tener que perder el tiempo constantemente comprobando usted mismo.

Tuve una fase en la que estaba absolutamente paranoico sobre el rendimiento. Pasé tanto tiempo tratando de mejorar el rendimiento que mi código nunca progresó realmente. No te metas en ese hábito :-)

Código, ENTONCES optimizar, no ambos al mismo tiempo.

Citar la "optimización prematura ... maldad" de Knuth es un argumento pobre para escribir código lento y descuidado (correcto o no).

Necesita métricas para optimizar.
Debes pensar en el código cuando lo estás codificando.
Solo optimiza el subconjunto de código que importa.

Si está escribiendo un formulario simple para actualizar algunos detalles, probablemente no valga la pena optimizarlo.

Si está escribiendo un reemplazo de un motor de búsqueda de Google y espera tener mucho tráfico, entonces encontrará la manera de realizar esa búsqueda lo más rápido posible.

Solo necesita optimizar el código que cuenta, y hay un montón de código en un programa para hacer cosas únicas, o eventos que ocurren con poca frecuencia.

Dado que satisfacemos 1, 2 y 3 arriba:

No tiene mucho sentido esperar hasta que la aplicación esté completa en un 90% antes de realizar cualquier prueba de rendimiento y optimización. El rendimiento a menudo es un requisito no funcional no escrito. Debe identificar y escribir cuáles son algunos de estos requisitos no escritos y comprometerse con ellos.

También es probable que sea demasiado tarde al 90% de completarse si necesita realizar cambios arquitectónicos u otros cambios importantes. Cuantos más códigos haya sido escrito, más difícil será cambiar las cosas, aunque solo sea por el hecho de que hay más código en qué pensar. Necesita asegurarse continuamente de que su aplicación funcionará cuando y donde sea necesario.

Por otra parte, si tiene pruebas de unidades bien escritas, debería poder tener pruebas de rendimiento como parte de esas pruebas.

Mis 2 chelines al menos.

Como han dicho otras personas, optimizar antes de conocer los problemas es una pérdida de tiempo. Recientemente trabajé en un código que tenía mucha optimización, ¡y la mayor parte de mi tiempo lo pasé eliminando la optimización! El problema fue que hizo que agregar la funcionalidad crítica fuera imposible.

Otro ejemplo ... en mi trabajo anterior trabajé en procesamiento de datos, escribiendo guiones alrededor de programas ejecutables. Si comencé un programa a las 5 p.m. por la noche y terminó a las 8 a.m. de la mañana siguiente, fue lo suficientemente rápido. Por supuesto, en el caso de una emergencia, era mucho mejor que tomara una hora en lugar de diez, y un código más rápido hacía mi trabajo más fácil, pero si funcionaba correctamente, 30 minutos equivaldrían a 16 horas.

Depende totalmente de su proyecto ... y debe considerarse en los requisitos de su proyecto.

Recuerde también que hacer que un programa sea más eficiente lleva más tiempo ... está negociando la velocidad de desarrollo para la velocidad de ejecución.

Creo que hay dos proverbios contradictorios que son relevantes aquí.

1: la optimización prematura es la raíz de todo mal.

2: mira antes de saltar.

En mi experiencia personal, ha sido el caso cuando se escribe el código por primera vez, la probabilidad de encontrar la magia del 3% del código que está usando el 90% de los recursos es muy fácil de encontrar. Aquí es donde el primer proverbio es relevante y parece producir excelentes resultados. Sin embargo, a medida que la base de código madura, parece ser que en lugar del 3% que usa el 90% de los recursos, de repente tiene el 50% usando el 90% de los recursos. Si imagina la analogía de una tubería de agua, en lugar de unas pocas fugas grandes, ahora tiene el problema de múltiples fugas pequeñas, por todo el lugar. Esto le da a la aplicación un rendimiento lento, incluso si es difícil definir una función individual.

Aquí es donde el proverbio 2 parece relevante. No confíe en el primer proverbio para no hacer ningún plan de rendimiento, tenga un plan general, incluso si es un proceso evolutivo. Trate de calcular algunas métricas de rendimiento aceptables y cronometrar su programa. Considere las implicaciones de rendimiento posteriores de las elecciones de diseño. Como ejemplo, uno podría planear usar una tienda de tuplas en lugar de una base de datos por adelantado si todo lo que se necesita es una tienda de tuplas. Comenzar con una base de datos SQL y luego cambiar a una tienda tuple más tarde es bastante difícil.

Sobre todo, intente optimizar dónde es fácil y tome notas sobre los casos donde la optimización es posible. Si no lo haces, a medida que pasa el tiempo, los programas tienden a sufrir la muerte de mil cortes, ya que el efecto de las funciones es un 5-20% más lento de lo que necesita sumarse y, de hecho, multiplicarse.

Desea pensar sobre el rendimiento con respecto a un problema en particular tan a menudo como sea posible para lidiar con problemas de rendimiento en cada tema un día.

Es decir, si no va a obtener mucho uso, preocúpese. No seas increíblemente vago o ineficiente, y no te obsesiones con obtener nirvana algorítmico cada vez. A menudo es mejor codificar de manera más simple y hacerlo más rápido / optimizado a medida que surgen las necesidades. Mientras tanto, cualquier desarrollador puede trabajar en un código simple y es algo que vale la pena considerar.

Si ves que su importancia aumenta, ahora sabes cómo pensarlo un poco más, ya que te morderá en la retaguardia.

Como desarrolladores tenemos un problema de querer un v1.0 perfecto. Un v1.0 en funcionamiento es todo lo que funciona, no es perfecto para cada situación que el futuro pueda traer.

Un buen ejemplo para mí fue cuando comencé a jugar con bases de datos hace muchos años. No sabía cuáles eran los índices adicionales o los incrementos en el rendimiento que ofrecen cuando las consultas disminuyen inimaginablemente.

No podemos predecir todos los problemas. Intento hacer un buen diseño y dejar que los problemas luchen por mi atención.

Espero que algo sea útil.

Encuentro que mi patrón típico para trabajar a través de una unidad de desarrollo es:

Reúna la versión mínima que funciona a través del caso de uso primario de principio a fin. En este paso, me enfoco principalmente en la simplicidad básica y una buena implementación de los patrones que se apliquen.
El paso 2 es refactorizar el paso 1, principalmente con miras a simplificar. Desde que he estado haciendo OOP, lo único en lo que parece poder contar es que este paso siempre presenta muchas simplificaciones obvias y una reducción real en el código. También es el punto donde las abstracciones obvias se caen (lo cual es otra simplificación). NOTA IMPORTANTE: Esto tiene un fuerte efecto secundario de abordar el rendimiento, especialmente cuando lo ha hecho varias veces y sabe dónde están los antipatrones de rendimiento.
A menudo, cuando se completa el n. ° 2, las cosas funcionan satisfactoriamente, pero las pruebas lo confirmarán o no; y también señale las ubicaciones (generalmente muy pocas) donde las optimizaciones deben abordarse.

Cada vez más veo que cada vez que paso pensando en el diseño eficiente en las fases 1 y 2, se altera la simplicidad, que en ese momento es primaria.

Estoy trabajando en la construcción de un motor de búsqueda. La optimización es lo que marca la diferencia entre que un usuario continúe buscando o abandonando el sitio web. Creo que es cierto para muchas aplicaciones, y desafortunadamente a muchas de ellas no les importa lo suficiente. A veces es mucho más económico tirar más hardware al problema. Lamentablemente, este último es más fácil. Para resumir, diría que tiene que optimizar cada vez que tenga que procesar MUCHOS datos y / o procesarlos muy rápidamente.

Lo mejor es escribir el código y luego identificar las áreas críticas que se beneficiarían más de la optimización.

Algunas veces el código es reemplazado, eliminado o refactorizado. Optimizar demasiado código puede ser una pérdida de tiempo valioso.

No pienses en el rendimiento hasta después de que lo hayas hecho correctamente. Si funciona correctamente y no tiene ningún problema de rendimiento notado por el usuario, no optimice.

Si funciona correctamente y tiene retrasos significativos y notables, no optimice . Perfil en su lugar. La mayor parte del tiempo de una aplicación se gastará en un solo bucle "caliente", y el bucle en el que se encuentra rara vez es intuitivo. Necesitas mediciones reales y ciencia para decirte lo que está sucediendo. Una vez que tenga los datos de su perfil, su tarea de optimización debería progresar de grande a pequeña:

Optimizaciones de arquitectura. ¿Es la estructura general de la aplicación la fuente de la inoperancia?
Optimizaciones de algoritmo: ¿está utilizando las estructuras de datos correctas? ¿Estás accediendo a ellos de la manera correcta? ¿Su aplicación pasa la mayor parte del tiempo escribiendo o la mayor parte del tiempo leyendo? Optimizar para la respuesta a esa pregunta.
Último recurso. Microoptimización. Racionalizar los bucles calientes o desenrollar algunos bucles. Dispositivo de Duff. No optimice en este nivel hasta que haya determinado que no puede hacer más mejoras en los otros dos niveles, y aún no ha cumplido sus objetivos de rendimiento. Este nivel de optimización tiene una alta probabilidad de romper una mierda y hacer que su aplicación sea más difícil de cultivar, más frágil, por lo tanto, no lo haga a menos que realmente deba hacerlo.

Una vez más, enfatizaré, no pierdas el tiempo optimizando solo cualquier código aleatorio que parezca ineficiente. El tiempo de optimización es una inversión significativa. Debe tener evidencia que lo respalde antes de jugar su tiempo con un perdedor.

Para mí, cuando estoy trabajando con manipulación de imágenes, múltiples consultas SQL grandes o bucles que superan la marca de 100k, pienso en la optimización. De lo contrario, no, a menos que vea que es lento cuando está funcionando.

Por lo general, se reduce a los requisitos. En algunos casos, tiene requisitos no funcionales muy estrictos para los tiempos de respuesta, etc. En esos casos, debe esforzarse más por modificar su código, procedimientos, etc.

Pero como regla general (en mi humilde opinión), debe construir su código en base a las mejores prácticas sobre confiabilidad y mantenimiento y luego realizar una ronda específica de pruebas de rendimiento. De esta forma, sabrá que solo ajustará los bits de código que realmente están afectando el rendimiento.

Respuesta 1:

Muchas personas dicen con acierto "No piensen en el rendimiento, optimícenlo más tarde", pero recuerden que tienen pruebas unitarias . Pueden reescribir grandes porciones de su base de código sin temor a introducir errores. Si reescribe sin pruebas unitarias, tiene que volver a probar manualmente todo, y esta vez es más difícil porque los algoritmos son más complejos.

Puede posponer la optimización hasta más tarde, pero debe asegurarse de estar preparado para ello. Si no tiene un plan viable para optimizar más adelante (pruebas unitarias, herramientas para crear un perfil de su código), entonces será mejor que piense en el rendimiento ahora porque le perjudicará mucho más adelante.

Respuesta 2:

A veces, la solución de trabajo simple que aparece por primera vez se ejecuta en O(n^n) vez. Si sabe que tendrá grandes conjuntos de datos, continúe y optimícelo ahora.

Respuesta 3:

Hace algún tiempo, me cansé de las imperfecciones en PHP e intenté arreglar algunas de ellas. Escribí un marco que involucraba una clase base de la que todo tenía que heredarse. Usó la sobrecarga de métodos y propiedades, la reflexión y prácticamente cualquier otra característica avanzada para que funcionase. Luego seguí adelante y lo utilicé en un proyecto masivo, utilizando mis propias características de framework en lugar de las características básicas del lenguaje como isset() y static . El código del proyecto era un poco más ordenado, pero la magia ralentizó cada llamada al método y el acceso a la propiedad en aproximadamente 50x.

Si va a tratar de ampliar el idioma en sí, debe pensar en el rendimiento ahora porque tiene que volver a escribir todo si no puede optimizarlo. C tiene un sistema macro de costo cero, ve por tu vida. Javascript no tiene dicho sistema, tenga mucho cuidado al escribir un nuevo sistema de herencia de objetos que quiera usar en todas partes.

El rendimiento no es algo que pueda pegarse al final de un proyecto.

No, si va a pensar en algo, piense en ofrecer valor a su empleador / cliente y a sus clientes. Piensa en lo que cuenta para ellos.

Dicho esto, el rendimiento es importante pero puede llevar a la ruina.

Dawn of War 2 se lanzó en febrero con un error que destruye múltiples jugadores. ¿La cuestión? Límite de población Cuando un escuadrón se refuerza, la última unidad toma el doble de la tapa debido a un error de codificación. Esto significa que puedes estar en una situación en la que tienes un ejército muy pequeño y cuando tratas de crear una nueva unidad, el juego te dice que tienes demasiadas unidades en el campo. Más frustrante

¿Por qué debería ser esto un problema? ¿Cómo puede ser esto un problema que solo ocurre con la reactivación? ¡Si fue un problema solo con comprar la unidad, seguramente se hubiera descubierto en las pruebas!

Bueno, supongo que se debe a una optimización prematura. El desarrollador no quería foreach todas las unidades cuando haces clic en el botón "comprar unidad" y en su lugar hace pop-cap como un banco, así que cuando se crea una unidad se saca el tope del banco y cuando muere se pone pop cap de vuelta al banco. Claro que es más eficiente, pero un pequeño error arroja a todo el banco fuera de lugar.

¿Qué es peor, un pequeño golpe de perforación cuando presionas ese botón de "comprar unidad" o llamas mucho en el foro de Dow2, los clientes enojados y MS arrastrando los talones con la certificación de la solución que significa que todavía no se ha solucionado?

En muchos casos, es mejor marcar un

// todo: performance could be better // try doing xyz if we need to improve it

porque la versión de rendimiento lleva más tiempo y agrega un costo de mantenimiento al código.

El rendimiento que debe preocuparse es ofrecer una solución a su cliente que sea satisfactoria y satisfaga sus necesidades. La velocidad de llegar a la fecha de lanzamiento suele ser más importante.

Hay escenarios en los que el rendimiento general es importante, como los sistemas integrados, pero esto debe conocerse como una restricción por adelantado y es un contexto especial del que debe tener en cuenta antes de ingresar al código.

Puedo estar en desacuerdo con la sabiduría comúnmente aceptada, pero creo que tienes que pensar en el rendimiento todo el tiempo. Sin embargo, lo importante es cómo piensas en el rendimiento.

A menudo, si comienzas a hablar sobre el rendimiento, otras personas comenzarán a hablar de optimización, algo prematuramente podría decir, ya que el rendimiento y la optimización no son lo mismo.

Prestar muy poca atención al rendimiento optimiza prematuramente las felicitaciones que se derivan de no optimizar de manera prematura.

Optimize es un verbo que toma un objeto. Hasta que tengas ese objeto, no puedes optimizarlo. Puede optimizar el código una vez que se ha escrito (aunque puede ser solo un método). Puede optimizar un modelo de clase o una especificación funcional una vez que se hayan escrito.

Trabajar en el rendimiento es una cuestión que apunta a lo óptimo, ya sea a priori o a posteriori . Algún tipo de trabajo de rendimiento solo es apropiado a posteriori y esto es lo que se debe considerar optimización, y es prematuro hacerlo a priori . Algún tipo de trabajo de rendimiento es, como mucho, apropiado a priori .

Lo principal para intentar acertar a priori es si su enfoque básico es razonable. Un ejemplo que a menudo se da aquí es el de la complejidad del tiempo de los algoritmos, pero tengo que estar en desacuerdo. No siempre es mejor hacer algo en O (1) u O (n log n) que en O (n). O (n) el tiempo es igual que O (1) tiempo cuando n es 1, y más rápido cuando n es 0, y los conjuntos de datos con 0 o 1 elemento pueden ser comunes en muchos casos. Más aún, la notación de complejidad de tiempo ignora deliberadamente los términos y constantes de orden inferior. Realmente O (n) time significa kn + c (y posiblemente otros términos de orden inferior) mientras que O (1) time significa k + c, pero para diferentes valores de k y c . Si este algoritmo se encuentra dentro de un bucle, es posible que O (n) supere masivamente a O (1).

Entonces, la complejidad del tiempo no es lo que debe considerarse aquí. Lo que debe considerarse aquí, es si la complejidad del tiempo es lo que se debe considerar aquí. Si es así, entonces es hora de ver si el caso donde O (n) supera a O (1) debido a la falta de sobrecarga, o si uno debe ir con el caso más común donde O (n) supera a O (1) , o si uno debe ignorar la complejidad del tiempo aquí y simplemente hacer lo que se lee de forma más natural . Por ejemplo, un caso común de competencia de complejidad de tiempo es si usar una lista y buscarla o un conjunto basado en hash y consultarlo en función del hash. Sin embargo, con la mayoría de las bibliotecas, el código de cada una se verá diferente, por lo que habrá una que describa mejor la intención, y esa será la única opción cuando no sea un elemento crítico.

Sin embargo, lo importante a priori sobre el rendimiento aquí fue si valía la pena pensar en el rendimiento en esta etapa.

Otro caso de enfoque básico es en cómo se manejan los recursos remotos. Si va a acceder al mismo recurso remoto que rara vez se ha modificado varias veces por segundo, debe asegurarse de que su código de acceso tenga algún grado de almacenamiento en caché o de que al menos le sea fácil colocarlo. Resistir a un enfoque particular del almacenamiento en caché puede ser prematuro o no, pero mezclar estrechamente su acceso con otros asuntos, por lo que es difícil agregar que el almacenamiento en caché más tarde es casi seguro una pesimción prematura.

Entonces, debemos pensar un poco desde el principio, aunque no necesitamos resolver todo en esta etapa.

Otro pensamiento razonable desde el principio es que no necesito pensar en el rendimiento de esta parte en este momento . Esto va con las personas que dicen no prestar atención al rendimiento a priori , pero en un nivel más detallado. Es poner una pequeña cantidad de pensamiento en una confianza razonable de que está bien no pensar con más detalle sobre el rendimiento.

Otro pensamiento razonable es que estoy bastante seguro de que el rendimiento de esta sección será crítico, pero todavía no puedo medir el impacto de los diferentes enfoques . Aquí ha decidido que la optimización probablemente sea necesaria, pero que apuntar a lo óptimo ahora sería prematuro. Sin embargo, puede sentar las bases haciendo que sus límites funcionales sean tales que pueda cambiar más fácilmente la implementación de la parte que se sospecha que es crítica, o tal vez poner código de registro de tiempo en esa función esp. en compilaciones de depuración, y esp. si está bastante lejos del método de llamada pública (por lo que no es equivalente a hacer el registro de tiempo en una prueba externa). Aquí no ha hecho nada a priori para hacer que el código sea más rápido, pero ha trabajado para ayudar a la optimización posterior.

Otra cosa en la que es razonable pensar es si algo debe hacerse de una manera múltiple, pero tenga en cuenta que hay tres pensamientos razonables; así como esto tendrá que ser de múltiples hilos y no será necesario que sea multihilo, también puede ser necesario que tenga varios hilos . De nuevo, puede definir límites funcionales de manera que sea más fácil volver a escribir el código para que ese método en particular se invoque en paralelo a otro trabajo.

Finalmente, debe pensar en lo capaz que será de medir el rendimiento después del hecho y la frecuencia con la que deberá hacerlo.

Un caso importante aquí es donde los datos subyacentes cambiarán a lo largo de la vida del proyecto. Con su historial de DBA, sabrá que la solución óptima para un conjunto particular de datos con un balance particular de frecuencia de operaciones no es la misma para diferentes datos con diferentes frecuencias de operación, incluso si los datos se ajustan al mismo esquema (p. Ej. las lecturas y escrituras intensas se beneficiarán menos de una indexación fuerte que el mismo esquema de tabla con muchas filas más, pocas escrituras y muchas lecturas). Lo mismo se aplica a las aplicaciones, por lo que debe considerar si va a tener que hacer la optimización en una fase posterior de optimización, o si tendrá que volver a la optimización con frecuencia a medida que cambian las condiciones. En este último caso, vale la pena asegurarse ahora de que es fácil cambiar las piezas que probablemente cambiarán en el futuro.

Otro caso importante es donde no podrá obtener fácilmente información sobre cómo se usa el código. Si está escribiendo una aplicación que se usa en un solo sitio, podrá medir esto muy bien. Si está escribiendo una aplicación que se distribuirá, esto se vuelve más difícil. Si está escribiendo una biblioteca que se utilizará en varias aplicaciones diferentes, entonces es aún más difícil. En el último caso, el argumento de que YAGNI se vuelve mucho más débil; tal vez alguien allí realmente necesita que el método lento sea mucho mejor y no lo sepas. Sin embargo, una vez más, el enfoque que debe tomar no es siempre el mismo; mientras que un enfoque es poner en marcha el trabajo por adelantado para hacerlo más eficiente en este caso (no del todo a priori, ya que es posterior a su biblioteca escrita, pero a priori para ser utilizado) otro enfoque es simplemente documentar que el método particular es necesariamente costoso y el código de llamada debe memorizar u optimizar la forma en que su propio código lo usa si es apropiado .

Constantemente, si es en su mayoría subliminal, pensar en el rendimiento es importante, es solo que la respuesta adecuada a ese pensamiento no siempre lo hace ir más rápido ahora .

Voy a estar en desacuerdo con el paquete aquí hasta cierto punto.

Siempre considera el rendimiento, pero esa consideración generalmente es descartarlo. Mire con qué frecuencia se ejecutará el código. Si la respuesta es "una vez" o "rara vez", el rendimiento básicamente no es un problema.

Solo cuando un fragmento de código se va a ejecutar con frecuencia, debe prestar atención al rendimiento. Incluso en este caso, generalmente solo debe mirar la clase O () de la rutina hasta que el perfil muestre un problema.

La única vez que consideraré algo como optimización detallada cuando estoy escribiendo originalmente es código dentro de una rutina O (temible). (Ejemplo: una prueba para asegurar que un conjunto de datos no contenía callejones sin salida. O (n ^ 8), aunque con poda sustancial. Fui cuidadoso con el rendimiento desde la primera línea).