c++ - Le app della console sono più veloci delle app GUI?



performance delphi (6)

le app della console funzionano più velocemente rispetto all'app per Windows

Risposta breve: no
Risposta lunga:

In un'applicazione basata su console, non esiste un thread GUI che deve ridisegnare le finestre e accettare l'input dell'utente, quindi in tal senso un'applicazione di console potrebbe essere leggermente più veloce (poiché ha un thread in meno che ruba i cicli della CPU). Tuttavia, poiché i sistemi operativi moderni eseguono più processi contemporaneamente, comunque, un'applicazione console sarebbe ancora in competizione per la CPU con altri processi nel sistema, quindi no.

le lingue come c e pascal sono più veloci dei linguaggi orientati agli oggetti come c ++ e delphi?

Risposta breve: no
Risposta lunga:

I programmi equivalenti in C e C ++ eseguono all'incirca lo stesso. Sebbene i linguaggi di programmazione possano sicuramente avere un ruolo nelle prestazioni, in genere la cosa principale di cui devi preoccuparti è l'algoritmo (ciò che stai esprimendo con la logica dell'applicazione) e non la lingua in cui è codificato l'algoritmo.

Sono relativamente nuovo al mondo della programmazione. Ho alcune domande sulle prestazioni:

  1. Le app della console sono più veloci delle app con un'interfaccia utente grafica?

  2. Le lingue come C e Pascal sono più veloci dei linguaggi orientati agli oggetti come C ++ e Delphi? So che la velocità della lingua dipende più dal compilatore che dal linguaggio stesso, ma i compilatori per i linguaggi procedurali producono codice più veloce di quelli OO (compresi i compilatori C ++ che possono produrre codice C)?


Answer #1

le lingue come c e pascal sono più veloci dei linguaggi orientati agli oggetti come c ++ e delphi?

No, anche il contrario può essere vero:

Come ha detto Dav nel suo commento, il codice deside quanto veloce sarà la tua applicazione. Questo vale anche per l'altro lato del compilatore, il codice macchina generato.

In generale, i nuovi compilatori spesso producono codice macchina più veloce, poiché utilizzano funzionalità avanzate della CPU ed eseguono ottimizzazioni del compilatore moderne che non si trovano nei compilatori precedenti.

Ad esempio, è possibile creare un'applicazione Pascal che gira più velocemente quando è compilata con Delphi piuttosto che con un vecchio compilatore Turbo Pascal.

In poche parole: non utilizzare i compilatori più vecchi / primitivi solo perché sembrano più leggeri. Nella maggior parte dei casi non otterrai alcuna prestazione.


Answer #2

Lo stesso codice generato dallo stesso compilatore verrà eseguito alla stessa velocità indipendentemente dal fatto che sia in esecuzione in un'app GUI o in una console. Inoltre il codice C compilato come C ++ (dato che è anche compatibile con C ++) non sarà significativamente differente se non lo stesso codice compilato come C.

Tuttavia ci sono aspetti del sistema operativo che possono influire sulle prestazioni, le app della console, a meno che non siano bloccate su un SO o una chiamata I / O, consumano l'intero intervallo di tempo; Le app GUI sono generalmente guidate dagli eventi, quindi aspetta un evento elaboralo, quindi attendi il prossimo evento; anche se potresti avere thread di lavoro che funzionano in modo simile alle app della console. Anche un'app GUI passerà necessariamente del tempo aggiornando la sua visualizzazione più complessa. Ma questi aspetti sono sotto il controllo del progettista dell'applicazione e del sistema operativo, non del compilatore.

In termini di OOP, non è intrinsecamente più lento, ma ci sono costrutti e architetture che portano a uno sviluppo di applicazioni più rapido ea una maggiore manutenibilità e robustezza, ma che possono comportare un compromesso con le prestazioni.


Answer #3

Michael Aaron Safyan ha già dato un'ottima risposta. Mi piacerebbe contribuire solo un po 'sul perché i linguaggi orientati agli oggetti a volte possono essere associati a un codice più lento.

Le esigenze del mondo reale nei confronti di noi programmatori continuano a costringerci a scrivere più codice in tempi più brevi. Dato programmatori molto abili, il linguaggio assembly vincerebbe ogni record di velocità perché il programmatore codifica esattamente le operazioni che la macchina deve eseguire, e molto poco altro. In pratica, la maggior parte della programmazione non viene eseguita in assembler perché è tediosa e soggetta a errori. I linguaggi compilati rendono i programmatori molto più produttivi perché consentono al compilatore di gestire gran parte dei dettagli.

Spostandosi ulteriormente nella stessa direzione, Delphi lavora con le stringhe automatiche: sono la lunghezza "giusta" ogni volta che vengono utilizzate; se si concatenano due stringhe, ne viene prodotta una nuova che è la lunghezza giusta per la combinazione delle stringhe precedenti. Se cambi quella stringa e la allunghi, viene creata una nuova stringa e la precedente viene scartata automaticamente. Come programmatore C, avresti potuto prevedere cosa avrebbe fatto il programma e assegnato spazio sufficiente per la stringa più grande, così non avresti dovuto crearne uno nuovo e scartare quello vecchio. Quindi la gestione della memoria per le stringhe è una comodità per il programmatore che viene acquistato a scapito del tempo di CPU.

Allo stesso modo, l'orientamento dell'oggetto consente di trattare gruppi di dati correlati come blocchi omogenei anziché stringhe e numeri. A volte non tutte queste informazioni sono necessarie, e in un programma C di basso livello si può fare a meno di alcune delle operazioni e della memoria che gli oggetti comportano. È ancora una volta una questione di convenienza per il programmatore rispetto alla velocità della CPU.

Infine, alcune interfacce sono considerate molto complicate e le aziende di software cercano di renderle accessibili creando framework orientati agli oggetti con una gestione concettualmente più semplice. Piuttosto che chiamare per aprire una finestra, puoi creare un oggetto finestra, di solito con un po 'di overhead. In uno sviluppo bizzarro, le società di software e gli sviluppatori individuali spesso costruiscono ulteriori framework object-oriented per nascondere o gestire la complessità di altri framework. Alcuni vecchi progetti finiscono con più livelli di framework orientati agli oggetti oltre alle funzionalità originali e, non sorprende che, trascorrendo così tanto tempo a gestire se stessi, mostrino prestazioni scadenti per il cliente mentre masticano molta memoria.

In sintesi, il codice orientato agli oggetti è talvolta associato a prestazioni scadenti a causa del modo in cui viene utilizzato; ma soprattutto nel caso del C ++, non c'è nulla direttamente nella lingua che rende "lento".


Answer #4

Poiché per l'assenza di mappe dei messaggi, eventi di finestre, thread della GUI, ecc ... l'app della console potrebbe sembrare avere prestazioni più veloci rispetto all'app basata su finestre. Ma per poter scegliere tra app per console e app basate su finestre, la velocità non dovrebbe essere l'unico criterio. Come forse saprai, le app di Windows sono "Programmazione guidata dagli eventi"

Per quanto riguarda la velocità della lingua, non posso dire che solo i compilatori c producano codice di esecuzione più veloce. Infatti i compilatori c ++ fanno molta ottimizzazione del codice per massimizzare la velocità del codice compilato. Anche i modelli OO sono così belli da programmare, mantenere ed estendere le funzionalità con facilità.

Quindi utilizzare linguaggio e tecnologia appropriati in base ai requisiti


Answer #5

Questo si applica solo alla tua prima domanda:

Quando le app della console vengono eseguite in modo interattivo in un ambiente grafico (ad esempio un desktop GNOME o Windows), lo fanno all'interno di una finestra del terminale che in realtà è un'app GUI. Quindi qualsiasi costo della GUI (come dover eseguire un loop di messaggi, non dover allocare i widget della GUI, ecc.) Viene semplicemente trasferito all'ambiente di hosting. L'esecuzione di un'app a console a schermo intero (schermate in modalità testo ) riduce il traffico tra la CPU e la scheda video, ma eventuali miglioramenti della velocità saranno trascurabili.

Tuttavia, le interfacce utente di console sono molto più facili da sviluppare a costo di essere meno flessibili con l'output grafico. Basta confrontare lo sforzo necessario per creare un modulo in ncurses rispetto a quello richiesto utilizzando GTK.





pascal