Rendimiento frente a la calidad del código

Question

¿Cree que vale la pena cambiar el rendimiento por la calidad del código y la mantenibilidad? Recuerdo una publicación de Jeff Atwood que decía que el hardware es barato, los desarrolladores no. Creo que me gustaría cambiar eso a "El hardware es barato, el tiempo no".

Me he dado cuenta con un proyecto de MVC en el que he estado trabajando últimamente que a veces pierdo DAYS solo tratando de sacar un poco de rendimiento extra de mi aplicación y estoy empezando a pensar que no vale la pena. Me acabo de dar problemas para diseñar una aplicación ASP.NET MVC. Me encanta la muerte IQuery en el hecho de que me permite agregar a la consulta para que pueda obtener un código fluido para su uso. Pero poder hacer algo así parece agregar más responsabilidad en el controlador/BLL.

¿Qué opinas? En el caso de las aplicaciones web, ¿estarías de acuerdo con intercambiar algún rendimiento por el código mantenible/limpiador? ¿Crees que es con tratar prematuramente de optimizar todo lo que puedas? Porque como hemos visto, no puedes predecir todos los requisitos.

Answer 1

1. hacer que funcione
2. Si el rendimiento es cuestionable, perfil e identificar el problema
3. solucionar el problema.
4. Repita los pasos 1 a 4 si es necesario
5. ???
6. beneficio

Answer 2

Realmente no creo que esto sea una u otra cosa. Si escribe un código simple y limpio que procesa solo exactamente la cantidad de veces que debería, tendrá uno de los mejores códigos posibles. Es realmente así de simple.

Answer 3

La respuesta obvia es depende. Si su aplicación es lo suficientemente lenta como para afectar la usabilidad de manera significativa, y tiene medidas para demostrar que sus optimizaciones realmente ayudan, entonces sacrificar la capacidad de mantenimiento puede ser una compensación razonable. Por otro lado, si no ha medido o la aplicación no es lo suficientemente lenta como para perjudicar la usabilidad, siempre busque legibilidad, facilidad de mantenimiento y flexibilidad. Esto simplemente se reduce a la optimización prematura siendo la raíz de todo mal.

Nota: El tiempo de diseño optimizaciones algorítmicas y arquitectónicas no son necesariamente malo si sabe el rendimiento va a importar para su aplicación, pero en el caso de su pregunta, que aparecen claramente a estar hablando de micro -Optimización, a lo que se aplica lo anterior.

Además, en su caso específico, si no puede decir si su aplicación es lo suficientemente lenta como para dañar la usabilidad, entonces es prematuro. Si puedes, entonces no lo es.

Answer 4

Definitivamente valor mi propio tiempo sobre el rendimiento de aplicaciones en el lado del servidor. Si noto que mi sitio no está funcionando lo suficientemente bien en las solicitudes de bases de datos, etc., la actualización del hardware del servidor es una solución alternativa que podría (al menos a corto plazo) resolver mi problema sin mirar el código.

Sin embargo, si la aplicación es extremadamente red -inefficient, me gusto mucho el tiempo tratando de mejorar esa parte. El envío de grandes cantidades de datos afecta a mis usuarios, sin importar lo que haga con mi propio servidor y enlace ascendente, y si no les gusta el rendimiento, no volverán.

Pero como varios otros han dicho, no es una cuestión de o/o - que depende mucho de la situación, lo pesado que es el problema de rendimiento, donde en la aplicación, etc.

Answer 5

Ni la calidad (es decir, fácil para leer) ni el rendimiento es lo más importante - ¡CORRECCIÓN!

Answer 6

Sir Tony Hoare dijo: "Deberíamos olvidarnos de las pequeñas eficiencias, digamos el 97% del tiempo: la optimización prematura es la raíz de todo mal".

La primera parte de la cita ha sido casi olvidada (no se sale de la lengua con tanta facilidad), y por lo tanto muchos ingenieros inexpertos no tienen en cuenta el rendimiento durante la fase de diseño de un proyecto de software. Esto casi siempre es un error fatal, ya que más tarde una aplicación mal diseñada es muy difícil de optimizar debido a fallas de diseño fundamentales. Al mismo tiempo, no tiene sentido tratar de ahorrar ciclos de CPU mediante el uso de astutos trucos cuando aún no se conocen los cuellos de botella de rendimiento.

En cuanto a su pregunta, creo que una aplicación diseñada correctamente que esté diseñada para hacer frente a sus requisitos de rendimiento particulares no tendrá que codificarse de manera "impura" o "no limpia". Solo cuando se descubren esos cuellos de botella de rendimiento (por ejemplo, descubre que su aplicación pasa el 90% de su tiempo en el 10% del código) puede considerar con moderación usando trucos de optimización en pequeñas cantidades de su código, para que permanezca mantenible y fácil de entender.

Lo bueno de muchas aplicaciones web es que el rendimiento se puede mejorar drásticamente utilizando varias técnicas de almacenamiento en caché. A medida que controlas el entorno del servidor (y, como dices, el hardware es barato), puedes asegurarte de guardar en caché todas esas partes de tu aplicación web comúnmente utilizadas. Esto realmente no crea un código que no se puede mantener si usas una capa de abstracción. Facebook es un buen ejemplo de una aplicación web que explota estupendamente el almacenamiento en caché (memcached) para su beneficio.

Answer 7

De acuerdo con esto hasta cierto punto. El tiempo del desarrollador es costoso, y la creación de perfiles y la optimización del código es una forma muy costosa de obtener, probablemente, poco rendimiento. Una vez dicho esto, depende del tipo de aplicación y del entorno en el que esté trabajando.

Si está trabajando en una aplicación web, puede realizar mejoras masivas solucionando algunos problemas simples (principalmente en el cliente) -lado). Cosas como reducir las solicitudes HTTP concatenando los archivos CSS/JS, crear sprites de imágenes, etc ... le darán grandes ganancias en comparación con el código de creación de perfiles, y son un buen uso del tiempo de los desarrolladores.

No obstante, no estoy de acuerdo con que el 'hardware sea más económico que la cotización de los desarrolladores'. Por supuesto, el hardware puede ayudarlo a escalar su aplicación y darle más potencia de rendimiento, pero lo último que desea hacer es confiar en un hardware robusto. Si su software está muy unido a su hardware, perderá mucha flexibilidad en términos de trasladarse a nuevos centros de datos, actualizar servidores, etc. ... y no tener esa flexibilidad puede ser muy costoso a largo plazo. Digamos que decide que la forma de escalar su aplicación de manera eficiente es pasar a la infraestructura EC2 de Amazon. Si su aplicación requiere 32 GB de RAM en cada servidor, encontrará que un movimiento como este podría requerir una nueva escritura.

Answer 8

Todas las buenas respuestas. La elección entre velocidad y código limpio es una dicotomía falsa.

No he visto que trabaja, pero he visto otros, y siempre es la misma historia:.

"No es lo suficientemente rápido Creo que el problema está en el código XXX.Creo que voy a pellizco que a ver si ayuda."

• usted NO saben el problema está ahí.
  Estás adivinando.

• nunca hacen nada basado en una suposición.
  (por supuesto que nunca haría eso, ¿verdad? Pero la mayoría de la gente hace.)

Podría crear un perfil del código.

Mi método favorito es detenerlo unas cuantas veces mientras está siendo lento, y preguntarle qué diablos está haciendo.

Por lo general, es una sorpresa que uno no podría haber adivinado.

Answer 9

Una definición estándar de calidad es "Conformidad con las expectativas del cliente (requisito)". Si ha realizado una buena recopilación de requisitos, entonces ha aceptado ciertos criterios de rendimiento. Si su aplicación cumple con este criterio, está perdiendo su tiempo y dinero, o el del cliente, tratando de hacerlo mejor.

Escribir código ligeramente acoplado, cohesivo y fácil de leer solo reduce el riesgo y el costo asociados con errores y cambios a los requisitos. Si está preparado para aceptar el riesgo de codificación de "bola de barro", continúe. Yo, me gusta obtener ganancias.

Answer 10

Antes de hablar sobre el rendimiento, realmente debe aprender sobre la notación O grande, puede buscarla en cualquier libro sobre algoritmos o en wikipedia.

La notación Big O dice algo acerca de cuánto tiempo tarda una función. Por ejemplo. Una lista que va de 0 a 100 tiene O (N). No importa cuán alto sea el número que cuente para que la notación O permanezca igual. Esta función tiene un tiempo de ejecución lineal y no se puede mejorar de ninguna manera.

Ahora si tienes una lista que va de 0 a 100 y para cada elemento de esa lista haces otra lista que va de 0 a 100 obtienes O (N^2) que es el doble de trabajo y tiene un tiempo de ejecución mucho peor que O (N).

Al escribir aplicaciones que tienen que tener un buen rendimiento, hablamos de obtener un buen tiempo de ejecución escrito en notación O. Si una ventana usa < 0.1 segundos o> 1 segundo realmente no importa si usan los mismos algoritmos.

Eso significa que el tiempo de afeitado de segundos probablemente no tenga una notación O diferente, por lo que no está realmente optimizando su código de ninguna manera. Entonces, para usted, escribir MVC en asp.net lo recomendaría céntrese en escribir código limpio y legible en su lugar :)

Cuando haya aprendido acerca de la notación O, podrá saber qué algoritmos elegir (cómo ordenar listas, poblarlos, recuperar datos) de una manera que use la menor ejecuta el tiempo en notación O y este conocimiento probablemente hará que tu código sea mucho más rápido que restar segundos a tu código al escribir loops difíciles.

Makach ^^

Answer 11

buen diseño menudo sacrifica algo de rendimiento para la mejora del programa general.Por ejemplo, escribir el código en capas tiene un costo, pero lo hacemos de todos modos porque hace que cambiar el código sea más fácil a largo plazo. Usamos servidores de aplicaciones de forma remota, no porque sea la manera más eficiente, sino porque se escala.

Recuerdo que desde Code Complete 2, McConnell sí da un ejemplo donde hacer el código horriblemente difícil de leer era necesario como una optimización. Ese ejemplo particular fue un algoritmo de encriptación. El programa se convirtió en un método para eliminar la sobrecarga de llamar a una función. Entonces, de hecho hay un momento y lugar para esto, pero creo que es raro.

En cuanto a la resolución de problemas de rendimiento, en la mayoría de los casos, he encontrado que los problemas de rendimiento están relacionados con la base de datos/IO o con pero (pérdida de memoria). Como otros han sugerido, perfilar es el camino a seguir, aunque todavía puede ser complicado rastrear muchos errores.

En cuanto al problema del hardware, el hardware se relaja pero no elimina la necesidad de un código optimizado. El hardware más rápido realmente solo nos permite usar idiomas que no sean óptimos y hacer cosas realmente agradables con la GUI.

Answer 12

Este es uno de los clásicos resultados de compensación versus compatibilidad. La primera vez que me encontré con este intercambio fue cuando escribí el código estructurado de COBOL (a principios de los 80). Quedó claro que al separar todo en módulos reutilizables creaba ramificación adicional y administración de punteros de pila y en las primeras computadoras se degradaba el rendimiento. La respuesta fue agrupar las funciones juntas (y duplicar ciertas funciones) para reducir el intercambio de códigos y las manipulaciones de los indicadores de pila que se usaban para llamar a los módulos. Esto causó un problema de compatibilidad.

Avanzando, más recientemente, tuve que desnormalizar una base de datos para crear objetos grandes que podrían almacenarse en caché. El problema aquí fue leer los derechos de acceso para roles y responsabilidades durante la navegación en un sistema CRM. Para resumir, la versión normalizada tomó demasiado tiempo para procesar y cargar cada pantalla, así que 30 años después todavía estoy involucrado en este clásico intercambio.