Gdzie mieści się Cel C w kontinuum wydajności językowej?

Wydaje się, że jest wiele dyskusji na temat różnych zalet szybkości dla C lub C ++ w porównaniu do powiedzenia Java lub Python, ale rzadko widzę wspomniany Cel C. Z grubsza, gdzie leży to pod względem wydajności językowej?

W przeciwieństwie do C ++, Objective-C został zaprojektowany jako czysty nadzbiór C. Niewiele kompilatorów Objective-C, których używałem, są lepiej znane jako kompilatory C, ale także obsługują Objective-C.

Można więc bezpiecznie założyć, że na poziomie generowania kodu C i Object-C są równoważne.

Pierwsza różnica pojawia się w OOP ABI, zwanym także „późnym wiązaniem metody”. Podobnie jak w C ++, Objective-C opiera się na tabelach wskaźników funkcji generowanych przez kompilator, które przechodzą w czasie wykonywania.

Jednak w przeciwieństwie do C ++ metoda wiązania jest bardziej „dynamiczna” i promuje stosowanie idnadklasy wszędzie, co czyni ją nieco wolniejszą niż C ++ w teorii. W praktyce różnica ta jest znacznie mniejsza niż mierzalna.

Wreszcie najważniejszym problemem związanym z wydajnością jest jakość używanych bibliotek. Ponieważ Objective-C jest naprawdę popularny tylko w systemach Apple, można założyć, że używasz go z kakao; który jest dobrym zestawem bibliotek wysokiego poziomu. W większości przypadków możesz zostawić im ciężkie podnoszenie, więc twój kod albo nie musi być tak szybki, albo jeśli wykonujesz ciężkie crunch, prawdopodobnie będzie to w większości statyczna baza kodu, mniej więcej podobna do zwykłego C .

TL; DR: jest tam właśnie w językach C i C ++, gdzie ma to największe znaczenie. Jeśli nie osiągasz dobrej wydajności, sprawdź swoje algorytmy; tak jak w każdym poważnym języku.

Cel C jest wolniejszy niż C / C ++. Powodem jest środowisko wykonawcze Objective-C, które dynamicznie wywołuje wyszukiwanie metod w środowisku wykonawczym w taki sam sposób, jak Smalltalk, z którego przejęło ten model wykonania. Wysyłanie wszystkich metod w czasie wykonywania jest nazywane „wysłaniem prawdziwej wiadomości”, w przeciwieństwie do wywołania funkcji w C / C ++, gdzie adres funkcji jest określany w czasie kompilacji (z wyjątkiem metod wirtualnych C ++). Ale nie mogę powiedzieć, o ile wolniejszy jest Cel C. ASAIK służy wyłącznie do tworzenia aplikacji ze względu na obniżenie wydajności.

Krótka odpowiedź: jest skompilowany do podobnego formatu jak C / C ++ / D / Go / Rust. Nie korzysta ze środowiska wirtualnego, takiego jak Java / .Net. I nie jest interpretowane jak Python / Ruby / Lua / JavaScript. Tak jest na szybszym końcu spektrum.

Podstawowe różnice prędkości między Obj-C i C / C ++, jak mówi poniżej Oliver, wynikają z dynamicznej wysyłki metod.

Ten artykuł profiluje ten narzut w Obj-C http://it.toolbox.com/blogs/macsploitation/bypassing-objectivecs-message-passing-mechanism-for-speed-24946

Zapewnia również bardzo dobrą sztuczkę optymalizacji kodu Obj-C, gdy określasz, że metoda wysyłania metod (tj. Objc_msgSend) jest czynnikiem ograniczającym - uzyskaj wskaźnik do funkcji jeden raz i użyj go, aby wywołać funkcję wiele razy. Nie powinno to zbytnio pomóc, ponieważ środowiska wykonawcze Obj-C przeprowadzają tę optymalizację automatycznie .

Należy pamiętać, że prawdziwy koszt dynamicznej wysyłki metody wynika z braków pamięci podręcznej, ponieważ przerywa przewidywanie gałęzi procesora. Są trudne do profilowania i być może kod cytowany powyżej nie mierzy rzeczywistego kosztu braku pamięci podręcznej.

Bardziej użyteczna dyskusja znajduje się tutaj: http://www.cocoabuilder.com/archive/cocoa/106535-instance-variable-access.html#106605

Podsumowując: największe różnice między językami to twoje algorytmy. Poza tym istnieje zasadnicza różnica prędkości między Obj-C, C i C ++, ze względu na dynamiczne lub wirtualne wysyłanie metod. Ten drugi punkt nie wydaje się być duży. A powyższy artykuł zawiera sposób na zoptymalizowanie go, jeśli można znaleźć punkty aktywne za pomocą profilowania, co może być trudne z powodu braków pamięci podręcznej procesora.