c++ - móviles - manual de programacion android pdf
¿Las aplicaciones de la consola se ejecutan más rápido que las aplicaciones GUI? (9)
¿Son idiomas como c y pascal más rápidos que los lenguajes orientados a objetos como c ++ y delphi?
No, incluso lo opuesto puede ser cierto:
Como dijo Dav en su comentario, el código indica cuán rápido será su solicitud. Esto también es cierto para el otro lado del compilador, el código de máquina generado.
En general, los compiladores más nuevos a menudo producen códigos de máquina más rápidos, ya que utilizan funciones avanzadas de CPU y realizan optimizaciones de compiladores modernas que no se encuentran en los compiladores anteriores.
Por ejemplo, es bastante posible crear una aplicación Pascal que se ejecute más rápido cuando se compila con Delphi en lugar de un viejo compilador de Turbo Pascal.
En pocas palabras: no use compiladores antiguos / primitivos solo porque parecen ser más livianos. En la mayoría de los casos, no obtendrá ningún rendimiento.
Soy relativamente nuevo en el mundo de la programación. Tengo algunas preguntas de rendimiento:
¿Las aplicaciones de la consola se ejecutan más rápido que las aplicaciones con una interfaz gráfica de usuario?
¿Los lenguajes como C y Pascal son más rápidos que los lenguajes orientados a objetos como C ++ y Delphi? Sé que la velocidad del lenguaje depende más del compilador que del propio lenguaje, pero ¿los compiladores de lenguajes de procedimiento producen código más rápido que los OO (incluidos los compiladores de C ++ que pueden producir código C)?
las aplicaciones de la consola se ejecutan más rápido que la aplicación basada en Windows
Respuesta corta: no
Respuesta larga:
En una aplicación basada en consola, no hay ningún subproceso de GUI que necesita volver a pintar las ventanas y aceptar la entrada del usuario, por lo que una aplicación de consola puede ser un poco más rápida (ya que tiene un hilo menos robando ciclos de CPU). Sin embargo, dado que los sistemas operativos modernos ejecutan múltiples procesos al mismo tiempo, de todos modos, una aplicación de consola todavía contendría por la CPU con otros procesos en el sistema, por lo que no.
¿Son idiomas como c y pascal más rápidos que los lenguajes orientados a objetos como c ++ y delphi?
Respuesta corta: no
Respuesta larga:
Los programas equivalentes en C y C ++ tienen aproximadamente el mismo rendimiento. Aunque los lenguajes de programación ciertamente pueden desempeñar un papel en el rendimiento, generalmente lo principal de lo que debe preocuparse es el algoritmo (lo que está expresando con la lógica de su aplicación) y no el lenguaje en el que está codificado el algoritmo.
Como ya se dijo, su código generalmente se ejecutará igual de rápido en una aplicación de consola que en una aplicación GUI.
La verdadera diferencia es sobrecarga. En igualdad de condiciones, las aplicaciones GUI son EXEs más grandes que tomarán un poco más de tiempo para iniciarse y cerrarse y consumirán más recursos. También es una buena forma de actualizar la interfaz de usuario a medida que se ejecuta la aplicación, lo que puede tomar ciclos de una tarea intensiva de la CPU.
Pero no debería importar en la mayoría de los casos.
Debido a la ausencia de mapas de mensajes, eventos de ventanas, hilos de la interfaz gráfica de usuario, etc., la aplicación de la consola podría tener un rendimiento más rápido que la aplicación basada en la ventana. Pero para que pueda elegir entre la aplicación de la consola y la aplicación basada en la ventana, la velocidad no debería ser el único criterio. Como sabrá, las aplicaciones de Windows son ''Programación impulsada por eventos''
En cuanto a la velocidad del lenguaje, no puedo decir que solo los compiladores de c produzcan un código de ejecución más rápido. De hecho, los compiladores de c ++ hacen mucha optimización de código para maximizar la velocidad del código compilado. También el modelo OO es tan bueno para programar, mantener y extender las funciones con facilidad.
Entonces use lenguaje y tecnología apropiados basados en el requerimiento
El mismo código generado por el mismo compilador se ejecutará a la misma velocidad, independientemente de si se está ejecutando en una aplicación GUI o una consola. Además, el código C compilado como C ++ (dado que también es compatible con C ++) no será significativamente diferente si es que proviene del mismo código compilado como C.
Sin embargo, hay aspectos del sistema operativo que pueden afectar el rendimiento, las aplicaciones de la consola a menos que estén bloqueadas en un sistema operativo o las llamadas de E / S consumirán todo el intervalo de tiempo; Por lo general, las aplicaciones de GUI son impulsadas por eventos, así que espere a que un evento lo procese, luego espere al próximo evento; aunque puede tener subprocesos de trabajo que funcionan de manera similar a las aplicaciones de consola. También una aplicación GUI necesariamente pasará tiempo actualizando su pantalla más compleja. Pero estos aspectos están bajo el control del diseñador de la aplicación y el SO, no del compilador.
En términos de OOP, no es intrínsecamente más lento, pero existen construcciones y arquitecturas que conducen a un desarrollo de aplicaciones más rápido y una mayor facilidad de mantenimiento y robustez, pero que pueden implicar un compromiso con el rendimiento.
En cuanto a su segunda pregunta, quiero hacerme eco de Michael y Carl, y agregar otra consideración: a saber, que la naturaleza aborrece el vacío, y esto se aplica al código fuente.
Como los lenguajes de nivel superior permiten hacer el mismo trabajo con menos código, también permiten trabajar más con el mismo código, incluso si no es necesario .
Entonces, por ejemplo, a veces ve en SO preguntas como esta:
time starttime = now;
for (i = 0; i < 1000000; i++){
cout << i;
}
cout << (now - starttime);
y preguntando si esto multiplica el ciclo, implicidad asumiendo que, dado que << es solo dos caracteres, es insignificante. De hecho, el << dentro del ciclo lleva miles de veces más ciclos que el ciclo. En mi experiencia, casi todos los programadores, incluido yo, lo hacen de muchas maneras, agradecen que se pueda hacer tanto con tan poco código, que lo hacen mucho y solo suponen que, si lo hicieron, fue necesario.
Por esa razón, cuanto mayor sea el nivel del idioma, más importante es la habilidad del ajuste del rendimiento .
Esto solo se aplica a su primera pregunta:
Cuando las aplicaciones de la consola se ejecutan interactivamente en un entorno gráfico (digamos un escritorio de GNOME o en Windows), lo hacen dentro de una ventana de terminal que en realidad es una aplicación GUI. Entonces, cualquier costo de GUI (como tener que ejecutar un bucle de mensajes, sin tener que asignar widgets de GUI, etc.) simplemente se transfiere al entorno de alojamiento. Ejecutar una aplicación de consola de pantalla completa (pantallas de modo de texto ) reduce el tráfico entre la CPU y su tarjeta de video, pero las mejoras de velocidad serán insignificantes.
Sin embargo, las IU de la consola son mucho más fáciles de desarrollar a costa de ser menos flexibles con la salida gráfica. Simplemente compare el esfuerzo que lleva crear una forma en ncurses frente a la requerida usando GTK.
Gracias a todos por ayudarme en este tema, pero todavía estoy confundido con mi impersión sobre los lenguajes OO, ya que tienen una sobrecarga de rendimiento porque sus bibliotecas están hinchadas. Si escribes en C ++ usando la biblioteca Blitz ++, funcionará más rápido si no tan rápido como c pero las bibliotecas normales disponibles para c ++ hacen que c ++ sea más lento que c, lo mismo aplica para pascal y delphi si usa delphi7 en lugar de delphi 2010 para compilar su programa funcionará más rápido porque las unidades delphi 2010 son más pesadas (advertencia: no he comparado Delphi 7 al 2010 ni ¿He comparado c ++ a c es solo mi impresión creada al leer foros en línea y debate de idioma frente a lenguaje? usted puede pensar que estoy loco pero preferiría un programa (incluso tan pequeño como editor de texto) para funcionar con perfección incluso si mis programas debían ejecutarse en una supercomputadora, me gustaría optimizar el funcionamiento de mi código, quizás tenga un trastorno obsesivo compulsivo de la personalidad :)
Michael Aaron Safyan ya ha dado una muy buena respuesta. Me gustaría contribuir un poco sobre por qué los lenguajes orientados a objetos a veces pueden asociarse con un código más lento.
Las exigencias del mundo real para los programadores nos siguen obligando a escribir más código en menos tiempo. Dado programadores muy hábiles, el lenguaje ensamblador ganaría cada récord de velocidad porque el programador codifica exactamente las operaciones que la máquina necesita realizar, y muy poco más. En la práctica, la mayoría de la programación no se realiza en ensamblador porque es muy tediosa y propensa a errores. Los lenguajes compilados hacen que los programadores sean mucho más productivos porque permiten que el compilador se encargue de gran parte del trabajo detallado.
Yendo más allá en la misma dirección, Delphi trabaja con cadenas automáticas: tienen la longitud "correcta" cada vez que se usan; si concatena dos cadenas, se produce una nueva que es la longitud correcta para la combinación de las cadenas anteriores. Si cambia esa cadena y la hace más larga, se crea una nueva cadena y la anterior se descarta automáticamente. Como programador en C, podrías haber anticipado lo que hará el programa y asignar suficiente espacio para la cadena más grande, por lo que no habría tenido que crear una nueva y descartar la anterior. Entonces, la administración de memoria para cadenas es una conveniencia para el programador que se compra a expensas de un poco de tiempo de CPU.
De forma similar, la orientación de objetos le permite tratar grupos de datos relacionados como fragmentos homogéneos en lugar de series y números. A veces no se necesita toda esta información, y en un programa C de bajo nivel, puede prescindir de algunas de las operaciones y el uso de memoria en que incurren los objetos. Una vez más, es una cuestión de conveniencia del programador sobre la velocidad de la CPU.
Finalmente, algunas interfaces se consideran muy complicadas, y las compañías de software intentan hacerlas accesibles mediante la creación de marcos orientados a objetos con un manejo conceptualmente más simple. En lugar de hacer la llamada para abrir una ventana, puede crear un objeto de ventana, generalmente con un poco de sobrecarga. En un desarrollo extraño, las compañías de software y los desarrolladores individuales a menudo crean marcos de trabajo orientados a objetos adicionales para ocultar o manejar la complejidad de otros marcos. Algunos proyectos antiguos terminan con múltiples capas de marcos orientados a objetos por encima de la funcionalidad original y, como era de esperar, como pasan mucho tiempo administrándose a sí mismos, muestran un rendimiento deficiente para el cliente a la vez que consumen mucha memoria.
En resumen, el código orientado a objetos a veces se asocia con un rendimiento deficiente debido a cómo se usa; pero especialmente en el caso de C ++, no hay nada directamente en el lenguaje que hace que sea "lento".