¿Es porque todos estos fueron escritos en lenguajes gestionados y recolectados de basura en lugar de código nativo?
No. El código lento funcionará mal independientemente. Claro, un idioma en particular puede introducir ciertas clases de problemas mientras resuelve otros. Pero los buenos programadores son bastante capaces de encontrar soluciones con el tiempo suficiente.
¿Son los programadores individuales quienes escribieron el software para estos dispositivos?
Parcialmente. En muchos casos es muy probable que sea al menos un factor contribuyente. Este es un efecto secundario desafortunado de una industria donde los buenos programadores tienen una gran demanda y escasez. También los abismos entre varios niveles de habilidad técnica pueden ser bastante grandes. Por lo tanto, es lógico que a veces los programadores encargados de implementar cierto software puedan ser felicitados solo por hacer que funcione (más o menos).
En todos estos casos, los desarrolladores de aplicaciones sabían exactamente a qué plataforma de hardware apuntaban y cuáles eran sus capacidades; ¿No lo tomaron en cuenta?
Parcialmente. Para empezar, probablemente no se conozca la plataforma de hardware exacta , ya que a menudo se negocia con varios fabricantes en paralelo durante el desarrollo de software. De hecho, incluso puede haber cambios pequeños (pero no necesariamente insignificantes) en el hardware subyacente después del lanzamiento inicial. Sin embargo, estaría de acuerdo en que se conocerán las capacidades generales.
Parte del problema es que el software probablemente no se desarrolla en el hardware, se hace en emuladores. Esto hace que sea difícil tener en cuenta el verdadero rendimiento del dispositivo, incluso si los emuladores son 100% precisos, lo cual no es cierto.
Por supuesto, esto realmente no justifica pruebas insuficientes en el prototipo de hardware apropiado antes del lanzamiento. Esa culpa probablemente yace fuera del control de dev / qa.
¿Es el tipo que anda repitiendo "la optimización es la raíz de todo mal", los llevó por mal camino?
No. Estoy bastante seguro de que no lo escuchan de todos modos; de lo contrario, no se lo citaría tan a menudo (se supone que es " optimización prematura ..."). :-RE
Es más probable que demasiados programadores tomen uno de los 2 extremos con respecto a la optimización.
- O bien lo ignoran por completo.
- O se obsesionan con minucias que no tienen nada que ver con los requisitos de rendimiento reales . El efecto neto es que el presupuesto se agota y el código está demasiado ofuscado para optimizar los problemas de rendimiento real de forma segura.
¿Era una mentalidad de "oh, son solo 100ms adicionales" cada vez hasta que todos esos milisegundos suman minutos?
Posiblemente. Obviamente, si Sleep(100)se ha utilizado como el equivalente del papel de seda utilizado para retrasar el sangrado de una extremidad cortada, entonces es de esperar problemas. Sin embargo, sospecho que el problema es más sutil que eso.
La cuestión es que el hardware informático moderno (incluidos los dispositivos integrados) es mucho más rápido de lo que la gente les da crédito. La mayoría de las personas, incluso los programadores "experimentados" no aprecian cuán rápido son las computadoras. 100 ms es mucho tiempo, mucho tiempo . Y como sucede, este "tiempo muy largo" corta 2 maneras:
- La primera es que los programadores se preocupan innecesariamente por las cosas que una computadora hace extremadamente rápido. (Da la casualidad de que fue tal preocupación " incrementar un valor 300 veces por segundo " lo que me llevó aquí en primer lugar).
- El segundo es que a veces no muestran la debida preocupación cuando las cosas toman mucho tiempo (en la escala de tiempo de computación). Asi que:
- si ignoran los efectos de la latencia cuando se comunican a través de una red o con un dispositivo de almacenamiento;
- si ignoran el impacto de un hilo bloqueado y esperando otro hilo;
- si olvidan que debido a que las computadoras funcionan tan rápido, es muy capaz de repetir una tarea con mucha más frecuencia de lo que debería, sin que el desarrollador sea consciente de un problema
- ... si se produce una combinación de tales descuidos, una rutina se ejecutará inesperadamente muy lentamente (en la escala de tiempo de computación). Algunas repeticiones e incluso los humanos lo notarán, pero puede ser difícil de precisar porque cientos de cosas interconectadas se ejecutan rápidamente por sí mismas.
¿Es mi culpa, por haber comprado estos productos en primer lugar?
Sí definitivamente. Bueno, no a usted personalmente sino a los consumidores en general. Los productos se venden (y compran ) mediante listas de verificación de características. Muy pocos consumidores exigen un mejor rendimiento.
Para ilustrar mi punto: la última vez que quise comprar un teléfono celular, la tienda ni siquiera podía ofrecer un modelo de demostración para jugar en la tienda. Todo lo que tenían eran conchas de plástico con pegatinas para mostrar cómo se vería la pantalla. Ni siquiera puede sentir el peso de esa manera, y mucho menos el rendimiento o la usabilidad. Mi punto es que si suficientes personas se opusieran a ese modelo de negocio y votaran con sus billeteras para expresar su objeción, seríamos un pequeño paso en la dirección correcta.
Pero no lo hacen, así que nosotros no; y cada año los nuevos teléfonos celulares funcionan más lentamente en hardware más rápido.
(Las preguntas no se hacen).
- ¿La gente de marketing tiene la culpa? Parcialmente. Necesitan fechas de lanzamiento. Y cuando se acerca dicha fecha, la elección entre "hacer que funcione" y "hacerlo más rápido" es obvio.
- ¿Son los vendedores los culpables? Parcialmente. Quieren más funciones en la lista de verificación. Exageran las listas de funciones e ignoran el rendimiento. Ellos (a veces) hacen promesas poco realistas.
- ¿Son los gerentes los culpables? Parcialmente. Los gerentes sin experiencia pueden cometer muchos errores, pero incluso los gerentes con mucha experiencia pueden (con bastante razón) sacrificar el tiempo para resolver problemas de rendimiento en favor de otras preocupaciones.
- ¿Son las especificaciones las culpables? Parcialmente. Si algo queda fuera de especificación, es mucho más fácil "olvidarlo" más tarde. Y si no se especifica específicamente, ¿cuál es el objetivo? (Aunque personalmente creo que si un equipo se enorgullece de su trabajo, se preocuparía por el rendimiento independientemente).
- ¿Es la educación la culpable? Tal vez. La educación probablemente siempre estará a la zaga. Ciertamente desapruebo la "educación" que rápidamente produce principiantes con un desarrollo de software de comprensión superficial. Sin embargo, la educación respaldada por la teoría e inculca una cultura de aprendizaje no puede ser mala.
- ¿Son las actualizaciones las culpables? Parcialmente. Nuevo software, hardware antiguo realmente es tentador destino. Incluso antes de que se lance la versión X, X + 1 está en planificación. El nuevo software es compatible, pero ¿el hardware antiguo es lo suficientemente rápido? ¿Fue probado? Se puede incluir una corrección de rendimiento particular en el nuevo software, fomentando una actualización de software desaconsejada.
Básicamente, creo que hay muchos factores que contribuyen. Entonces, desafortunadamente no hay una bala de plata para arreglarlo. Pero eso no significa que sea pesimismo. Hay formas de contribuir a mejorar las cosas.
Entonces, ¿en qué punto las cosas salieron mal para estos productos?
En mi humilde opinión, realmente no podemos identificar ningún punto único. Hay muchos factores contribuyentes que evolucionaron con el tiempo.
- Contadores de frijoles: reducción de costos, sincronización del mercado. Pero, de nuevo, ¿habríamos logrado los avances que hemos logrado sin la presión?
- Alta demanda y baja oferta de personas calificadas en la industria. No solo programadores, sino también gerentes, evaluadores e incluso vendedores. La falta de habilidades y experiencia conduce a errores. Pero, de nuevo, también conduce al aprendizaje.
- Tecnología de última generación. Hasta que una tecnología madure, morderá regularmente de maneras inesperadas. Pero, de nuevo, a menudo proporcionó una serie de ventajas en primer lugar.
- Complicación compuesta. Con el tiempo, la industria ha evolucionado: agregando más herramientas, tecnologías, capas, técnicas, abstracciones, hardware, idiomas, variaciones, opciones. Esto hace que sea algo imposible tener una comprensión "completa" de los sistemas modernos. Sin embargo, también somos capaces de hacer mucho más en un tiempo mucho más corto como resultado.
¿Qué podemos hacer nosotros como programadores para evitar infligir este dolor a nuestros propios clientes?
Tengo algunas sugerencias (tanto técnicas como no técnicas) que pueden ayudar:
- En la medida de lo posible, use su propio producto. No hay nada como la experiencia de primera mano para revelar cosas incómodas, lentas o inconvenientes. Sin embargo, deberá evitar conscientemente eludir las deficiencias debido al "conocimiento interno". Por ejemplo, si no tiene problemas para sincronizar contactos porque lo hace con un script de Python de puerta trasera, no está utilizando "el producto". Lo que trae el siguiente punto ...
- Escuche a sus usuarios (preferiblemente de primera mano, pero al menos de segunda mano a través del soporte). Sé que los programadores (en general) prefieren permanecer escondidos y evitar la interacción humana; pero eso no lo ayuda a descubrir los problemas que otras personas experimentan al usar su producto. Por ejemplo, es posible que no note que las opciones del menú son lentas, porque conoce todos los accesos directos y los usa exclusivamente. Incluso si el manual documenta completamente todos los accesos directos, algunas personas seguirán prefiriendo los menús, a pesar de ser insufriblemente lentos.
- Esfuércese por mejorar sus habilidades técnicas y conocimientos de forma continua. Desarrolle la habilidad para analizar críticamente todo lo que aprende. Vuelva a evaluar sus conocimientos regularmente. En algunos casos, prepárate para olvidar lo que creías saber. Lo que trae a colación ...
- Algunas tecnologías / técnicas pueden ser muy complicadas y llevar a malentendidos sutiles e implementaciones incorrectas. Otros, a través de la evolución del conocimiento común o las herramientas disponibles, pueden caer en desgracia (por ejemplo, Singletons). Algunos temas son tan complicados que generan un montón de "expertos hocus-pocus" que propagan una enorme cantidad de información errónea. Un error particular para mí es la información errónea que rodea a los subprocesos múltiples. Una buena implementación de subprocesos múltiples puede mejorar significativamente la experiencia del usuario. Desafortunadamente, muchos enfoques mal informados sobre subprocesos múltiples reducirán significativamente el rendimiento, aumentarán los errores erráticos, aumentarán los riesgos de bloqueo, complicarán la depuración, etc.
- Tomar posesión. (No, en serio, no estoy jugando al bingo de la sala de juntas). Negocie con gerentes, propietarios de productos y vendedores para obtener características de rendimiento que tengan prioridad sobre algunos elementos de la lista de verificación. Exija mejores especificaciones. No infantilmente, sino haciendo preguntas que hacen que las personas piensen en el rendimiento.
- Sé un consumidor exigente. Elija el teléfono que tiene menos funciones pero es más rápido. (No es una CPU más rápida, una IU más rápida). ¡ Entonces presume ! Mientras más consumidores comiencen a exigir un rendimiento, más contadores de frijoles comenzarán a presupuestarlo.