Ich habe mit der Audioprogrammierung für das iPhone einige Fortschritte gemacht. Jetzt mache ich eine Leistungsabstimmung und versuche zu sehen, ob ich mehr aus dieser kleinen Maschine herauspressen kann. Running Shark, ich sehe, dass ein wesentlicher Teil meiner CPU-Leistung (16%) von objc_msgSend aufgefressen wird. Ich verstehe, dass ich das etwas beschleunigen kann, indem ich Zeiger auf Funktionen (IMP) speichere, anstatt sie mit der [Objektnachrichten] -Notation aufzurufen. Aber wenn ich all diese Probleme durchgehen werde, frage ich mich, ob ich besser mit C ++ umgehen könnte.
Irgendwelche Gedanken dazu?
Das Problem mit Objective-C und Funktionen wie DSP ist nicht die Geschwindigkeit an sich, sondern vielmehr die Unsicherheit, wann die unvermeidlichen Engpässe auftreten.
Alle Sprachen haben Engpässe, aber in statisch verknüpften Sprachen wie C ++ können Sie besser vorhersagen, wann und wo im Code sie auftreten werden. Im Fall der Laufzeitkopplung von Objective-C, die Zeit, die benötigt wird, um das geeignete Objekt zu finden, ist die Zeit, die zum Senden einer Nachricht benötigt wird, nicht langsam, sondern variabel und unvorhersehbar. Die Flexibilität von Objective-C bei der Benutzeroberfläche, der Datenverwaltung und der Wiederverwendung funktioniert dagegen bei zeitlich eng begrenzten Aufgaben.
Die meiste Audioverarbeitung in der Apple-API erfolgt in C oder C ++, da die Zeit, die für die Ausführung des Codes benötigt wird, festgelegt werden muss. Es ist jedoch leicht, Objective-C, C und C ++ in der gleichen App zu mischen. Dies ermöglicht Ihnen, die beste Sprache für die unmittelbare Aufgabe auszuwählen.
Objective C ist absolut schnell genug für die DSP / Audio-Programmierung, weil Objective C eine Obermenge von C ist. Sie müssen (und sollten nicht) alles zu einer Nachricht machen. Wenn die Leistung von entscheidender Bedeutung ist, verwenden Sie einfache C-Funktionsaufrufe (oder verwenden Sie Inline-Assembly, wenn es Hardwarefunktionen gibt, die Sie auf diese Weise nutzen können). Wenn die Leistung nicht kritisch ist und Ihre Anwendung von den Funktionen der Nachrichtenindirektion profitieren kann, verwenden Sie die eckigen Klammern.
Das Accelerate-Framework unter OS X ist beispielsweise eine großartige Objective-C-Hochleistungsbibliothek. Es verwendet nur standardmäßige C99-Funktionsaufrufe, und Sie können sie aus Objective C-Code ohne Umbruch oder Indirektion aufrufen.
Ist Objective C schnell genug für die DSP / Audio-Programmierung
Echtzeitwiedergabe
Definitiv nicht . Die Objective-C-Laufzeit und ihre Bibliotheken sind einfach nicht für die Anforderungen von Echtzeit-Audio-Rendering ausgelegt. Tatsache ist, dass es praktisch unmöglich ist, zu garantieren, dass die Verwendung der ObjC-Laufzeitumgebung oder von Bibliotheken wie Foundation (oder sogar CoreFoundation) dazu führt, dass Ihr Renderer seine Frist nicht verfehlt.
Der übliche Fall ist eine Sperre - selbst eine einfache Heap-Zuweisung ( malloc , new / new[] , [[NSObject alloc] init] ) wird wahrscheinlich eine Sperre erfordern.
Um ObjC zu verwenden, benutzt man Bibliotheken und eine Laufzeitumgebung, die davon ausgehen, dass Sperren an jedem Punkt ihrer Ausführung akzeptabel sind. Die Sperre kann die Ausführung Ihres Render-Threads (z. B. während des Render-Rückrufs) unterbrechen, während Sie auf die Sperre warten. Dann können Sie Ihren Render-Termin verpassen, weil Ihr Render-Thread aufgehalten wird, was schließlich zu Dropouts / Glitches führt.
Fragen Sie einen Pro-Audio-Plugin-Entwickler: Sie werden Ihnen sagen, dass das Blockieren innerhalb der Echtzeit-Render-Domain verboten ist. Sie können z.B. Führen Sie das Dateisystem aus, oder erstellen Sie Heapzuweisungen, da Sie keine praktische Obergrenze für die Zeit haben, die zum Beenden benötigt wird.
Hier ist eine nette Einführung: Ссылка
Offline-Rendering
Ja, es wäre in den meisten Szenarien für High-Level -Messaging akzeptabel schnell. Auf den unteren Ebenen empfehle ich die Verwendung von ObjC, weil es verschwenderisch wäre - es könnte viel, viel länger dauern, wenn ObjC-Messaging auf dieser Ebene verwendet wird (im Vergleich zu einer C- oder C ++ - Implementierung).
Siehe auch: Wird meine iPhone App einen Leistungseinbruch erleiden, wenn ich Objective-C für Low-Level-Code verwende?
objc_msgSend ist nur ein Dienstprogramm. Die Kosten für das Senden einer Nachricht sind nicht nur die Kosten für das Senden der Nachricht. Es sind die Kosten, alles zu tun, was die Nachricht initiiert. (Genau wie die wahren Kosten eines Funktionsaufrufs sind seine einschließlich -Kosten, einschließlich I / O, falls es welche gibt.)
Was Sie wissen müssen, ist wo sind die zeitdominanten Nachrichten, die kommen und gehen und warum . Stack-Beispiele werden es zeigen Sie welche Routinen / Methoden werden so oft aufgerufen, dass Sie herausfinden sollten, wie Sie sie effizienter aufrufen können.
Sie werden feststellen, dass Sie sie mehr anrufen, als Sie müssen.
Besonders wenn Sie feststellen, dass viele der Aufrufe zum Erstellen und Löschen der Datenstruktur dienen, können Sie wahrscheinlich bessere Möglichkeiten finden, dies zu tun.
Tags und Links objective-c iphone performance audio