Dove si colloca l'Objective-C nel continuum delle prestazioni linguistiche?

Diversamente dal C ++, Objective-C è progettato come un superset pulito di C. I pochi compilatori Objective-C che ho usato sono meglio conosciuti come compilatori C, ma gestiscono anche Objective-C.

Quindi, è sicuro assumere che nel livello di generazione del codice, C e Objective-C siano equivalenti.

La prima differenza appare nell'ABI OOP, chiamato anche "binding del metodo tardivo". Proprio come in C ++, Objective-C si basa su tabelle di puntatori a funzioni generate dal compilatore che vengono attraversate in fase di runtime.

Diversamente dal C ++, tuttavia, il metodo di bind è più "dinamico" e promuove l'uso della superclasse id ovunque, rendendo in teoria leggermente più lento del C ++. In pratica, questa differenza è molto inferiore al misurabile.

Infine, il problema di prestazioni più importante è la qualità delle librerie utilizzate. Poiché Objective-C è molto popolare solo nei sistemi Apple, è ragionevole presumere che tu stia usando Cocoa; che è un bel set di librerie di alto livello. Nella maggior parte dei casi, puoi lasciare il carico pesante a loro, in modo che il tuo codice non debba essere così veloce, o se fai crunch pesante, allora è probabile che sia una base di codice prevalentemente statica, approssimativamente simile alla semplice C .

TL; DR: è proprio lì con le lingue C e C ++ dove conta di più. Se non stai ottenendo buone prestazioni, controlla i tuoi algoritmi; proprio come in qualsiasi linguaggio serio.

L'obiettivo-C è più lento di C / C ++. Il motivo è il runtime di Objective-C che invia metodi di ricerca dinamici in fase di esecuzione allo stesso modo di Smalltalk, dal quale ha preso il sopravvento su questo modello di esecuzione. Invia tutti i metodi in fase di runtime è chiamato "invio di messaggi veri" in contrapposizione alla chiamata di funzione in C / C ++, dove l'indirizzo della funzione viene determinato al momento della compilazione (eccetto per i metodi virtuali C ++). Ma non posso dire quanto sia più lento l'Objective-C. ASAIK è usato solo per lo sviluppo di applicazioni a causa della penalizzazione delle prestazioni.

Risposta breve: È compilato in un formato simile a C / C ++ / D / Go / Rust. Non usa un ambiente virtuale come Java / .Net. E non è interpretato come Python / Ruby / Lua / JavaScript. Quindi è alla fine più veloce dello spettro.

Le differenze di velocità fondamentali tra Obj-C e C / C ++, come dice Oliver di seguito, sono dovute all'invio del metodo dinamico.

Questo articolo descrive questo sovraccarico in Obj-C link

Fornisce anche un trucco molto bello per l'ottimizzazione del codice Obj-C quando si determina la spedizione del metodo (ad esempio objc_msgSend) è il fattore limitante: ottenere un puntatore alla funzione una sola volta e utilizzarlo per chiamare la funzione più volte. Non dovrebbe aiutare troppo come Reti Obj-C fai questo ottimizzazione automatica .

Si noti che il costo effettivo dell'invio del metodo dinamico è dovuto a errori di cache, poiché interrompe la previsione del ramo CPU. Questi sono difficili da profilare e può darsi che il codice sopra citato non misuri il vero costo della cache mancante.

Qualche discussione più utile è qui: link

In conclusione: le maggiori differenze tra le lingue sono i tuoi algoritmi. Oltre a ciò, vi è una fondamentale differenza di velocità tra Obj-C, C e C ++, a causa dell'invio del metodo dinamico o virtuale. Questo secondo punto non sembra essere grande. E l'articolo sopra fornisce un trucco per ottimizzarlo, se puoi trovare degli hot spot tramite il profiling, che può essere difficile a causa di errori di cache della CPU.