@Kay

Die Ignore-Funktion hat irgendwie einen Fehler.

+++

Ich bin es leid.

Ich bin es leid, hier im Forum meine Zeit zu opfern.

Ich bin es leid, hier deutlich mehr hereinzustecken, als herauszubekommen.

Ich bin es leid, dass Leute etwas schreiben, was zwei Beiträge später ganz anders gemeint war.

Ich bin es leid, eine Sachdiskussion in persönlichen Angriffen enden zu sehen.

Ich bin es leid. Einfach leid.

Ich habe überreagiert und mit dir hat es ohnehin der Falsche abbekommen.

Als ich deine Mail las, wollte ich meinen Beitrag löschen, sah aber, dass du bereits an einer Antwort sast. Das wäre ja nun auch unfair.

Ansonsten: Siehe Mail. Deine Kritik ist durchaus berechtigt.

BTW: Im Code sollte es && statt & heißen.

BTW: Hast du meine letzte Mail bekommen? Irgendwie spinnt web.de in letzter Zeit.

Zurück zum Thema:
Bindings sind auf tiefer Ebene von Apple mit Bedacht auf Hochperformance implementiert worden.

Sobald du ein zweites View, welches das Attribut anzeigt, besteht die Alternative in manuellen Display-Listen. Das wird nicht schneller.

Abstraktion bedingt eine Indirektion. Indirektion kostet Laufzeitverhalten.
Abstraktion bringt Verstehen. Verstehen bringt Laufzeitverhalten.

Es lässt sich einfach nicht abstrakt werten.

Ganz wichtig ist auch noch das hier:
developer.apple.com/documentat…ple_ref/doc/uid/10000151i

Mich wundert es jedenfalls in aller Regel, wie unkritisch alles außer zeichnen ist.

Original von MCDan
Bei Verwendung einer NSTableDataSource müsste man doch ein reloadData auf den NSTableView triggern, oder?

Naja, man kann auch per dataSource einzelne Zellen aktualisieren ([tv setNeedsDisplayInRect:[tv frameOfCellAtColumn:col row:row]]), aber Du hast vollkommen Recht: Bindings machen das schon ausgezeichnet - wozu soll man den Aufwand treiben, wenn es schon einen ziemlich genialen Mechanismus dafür gibt? Bei solchen Sachen ist es schon eine mutige Herausforderung, schlauer als Bindings sein zu wollen...

Original von obb
Da wird die Position über die Wellenform gezeichnet (OpenGL mit gebufferter Texture, dank dir), und zum anderen eben die Zeit-Anzeige mit TextField. (Oben habe ich fälschlicherweise TextView geschrieben).

Timecode-Anzeigen sind interessant, weil viele Nutzer beim Abspielen in der Tat unsinnig und unlesbar schnell durchlaufende Zahlen erwarten. Vielleicht wäre es da sinnvoll, sich einen Custom View zu basteln, der nicht jedes Mal das komplette Textlayout anwirft (sind ja normalerweise Monospace-Fonts und es ändert sich meistens nur ein kleiner Teil) - und die maximale Ausgabegeschwindigkeit drosselt. Ich hatte mal eine Timecode-Anzeige, die das Ganze auf 7/100-Sekunden begrenzt hat - weil bei der Rate die Zehntel noch sauber durchlaufen und bei den Hundertsteln eine wild aufeinanderfolgende Ziffernfolge entsteht, genau das, was die Leute zu sehen erwarten. Für manuelle Positionierung reicht die Reaktionszeit auch locker. Aber auch hier wäre für mich die Frage, wie ich das Model sauber vom View entkoppele, was die Eigenschaft und was die Ansicht davon ist. Wie das geht, hängt von der Modellierung der Abspielposition ab.

Zum OpenGL-View hatte ich, glaube ich, schon im damaligen Thread erwähnt, dass es sich auch bei OpenGL-Views lohnen kann, nicht immer alles neu zu zeichnen, sondern den Dirty-Rect-Mechanismus von Cocoa zu nutzen. Ob das (und das Limit der TC-Anzeige) wirklich etwas bringt, kann ich nicht sagen - Shark schon eher.

Original von below
Aber der theoretische Informatiker würde ja zu Bindings vs. keine Bindings sagen, dass sich da sowieso nur maximal ein linearer Faktor rausholen lässt, die Geschichte von der Komplexität her also gleich bleibt

Stimmt - wenn man's richtig macht, sollte das so sein, bezüglich Laufzeitverhalten. Beim Entwicklungszeitverhalten sieht das vermutlich ganz anders aus...

Original von Tom9811
Und das meint auch Knuth: Er ist sicherlich *für* den Ansatz mit einem guten Design, welches nachher punktuell verbessert werden kann.

Knuth würde so etwas vermutlich mit Literate Programming machen: Ein gutes Design, das später nicht mehr verbessert werden muss - aber wahrscheinlich steht die endgültige Antwort erst im siebten Band...

Bei literarischer Programmierung wundert es mich nicht, wenn die Antwort auf sch warten lässt.

Ich ärgere mich ja selbst häufig genug darüber, wie wenig ich kommentiere. Aber für literarische Programmierung bin ih einfach zu neugierig auf die Problemlösung, die praktische, nicht die theoretische. Da fehlt mir einfach die Geduld.

Ich hab' mir nicht ganz genau angesehen, was Dein Test macht, aber anscheinend geht es da nicht um das Rendern des Textes (ich habe ihn zumindest nicht gesehen). Egal - auch so gibt er Dir die Sicherheit, dass das Optimieren an der Stelle nichts bringt:

1,26 Sekunden Differenz auf 100000 Werte sind selbst bei einem üppigen Framecap von 30 fps (und einem entsprechend gedrosselten Datenfluss vom Model zum View) ein Sparpotenzial von 0,000378s pro Sekunde, also etwa 0,04 Prozent Prozessorlast. Also sitzen die Performancefresser vermutlich woanders. Anders sieht die Sache natürlich aus, wenn Du den Wert unnütz häufig überträgst. Dann dürfte aber das Rendern erheblich mehr ziehen als die Übertragung - das wäre mal ein interessanter Performancetest, andererseits hast Du doch schon Deine Anwendung und kanns das Profiling gleich am Patienten machen, oder?

Original von obb
Wie schon ganz am Anfang gesagt. Es geht bei meiner Frage eigentlich nur darum, wie viel "kostet" der Komfort der Bindings.
Und das kostet in diesem Fall (der Text wird ja erst gar nicht upgedatet) auf jeden Fall 6.7 mal mehr Zeit als wenn ich werte über Outlets übertrage.
Mit dieser Erkenntnis kann ich von Fall zu Fall entscheiden.

Ich weiß ehrlich nicht, was die Zahl 6,7 an anwendbarer Erkenntnis bringen soll - das Beispiel ist ja insofern realitätsfremd, dass man normalerweise Daten an einen View gibt, damit der etwas damit macht (typischerweise sie darzustellen). Und sobald man den Renderaufwand dazu nimmt, ist der Faktor ein ganz anderer. In Deinem Beispiel wird ja nichts dargestellt, weil die Schleife den Hauptthread blockiert. Ich habe mir mal den Spaß eines anderen Vergleichs gegönnt. Dein Testprogramm, TextField über Outlet: Einmal so wie es war (ohne Darstellung) und einmal mit erzwungenem Rendering ([text1 display] nach dem setObjectValue) - um zu sehen, wie das Verhältnis zwischen Transfer und Darstellung ist.

Ohne -display: 0,18s
Mit -display: 1562,75s (eine knappe halbe Stunde)

Jetzt kann man natürlich über vier Sekunden mehr oder weniger bei Bindings diskutieren (es wären dann 1566s) - und man kann das sicherlich ganz toll optimieren, aber angesichts dieser Verhältnisse vermute ich, dass das nicht viel bringen wird. Die Rechenzeit versickert in der Zeichenroutine des TextFields. Wenn es mein Projekt wäre, würde ich mir überlegen, wie ich die Darstellung effizienter bekomme - unabhängig von Bindings oder nicht.

Also jetzt verstehe ich dich nicht (mattik)

Es geht doch nur darum den Unterschied zweischen Binding und direktem Zugriff festzustellen, also diesen Mechanismus zu isolieren und zu untersuchen. Genau da wäre ja das Rendern von irgendwas ein Faktor der enorm verzerrt.

Ich hab nun keine Ahnung, ob obbs Teststellung tatächlich den Mechanismus der Bindings einigermaßen isoliert untersucht. Aber es wäre auf alle Fälle ein bemerkenswertes Ergebnis.

Ob das in der Praxis dann greift ist was anderes. Ist irgendwie so wie der Vergleich eine c Funktion aufzurufen und eine ObjC Methode zu benachrichtigen. Die c Funktion ist schneller, wenn ich dann aber in der Funktion eine Nuklearexplosion durchrechne durfte der eigentliche Aufruf wohl kaum ins Gewicht fallen.

Aber die Frage ist nicht, wie groß der Unterschied zwischen Bindings/Direktaufruf und den Zeichnen einer View ist, sondern der Unterschied zwischen Binding und Direktaufruf.

Original von kressevadder
Also jetzt verstehe ich dich nicht (mattik)

Es geht doch nur darum den Unterschied zweischen Binding und direktem Zugriff festzustellen, also diesen Mechanismus zu isolieren und zu untersuchen. Genau da wäre ja das Rendern von irgendwas ein Faktor der enorm verzerrt.

Es kommt drauf an, was man messen bzw. vergleichen will. Obbs Test ist in der Tat interessant, weil er den Kern der Mechanismen isoliert. Sozusagen ein Laborversuch. Da kommt raus, das Bindings um ein Vielfaches langsamer sind als ein direkter Push. Das ist doof, andererseits aber auch verständlich, schließlich hängt eine ganze Indirektionsebene dazwischen - der direkte setObjectValue wird vermutlich nicht viel mehr machen als sich das Objekt zu merken und needsDisplay zu setzen.

Der Faktor 6,7 ist unbestritten eine Erkenntnis. Meine Anmerkung bezog sich darauf, inwiefern diese Erkenntnis im Programmieralltag _anwendbar_ ist, insb. auf die ursprüngliche Situation: Ein Wert im Model ändert sich häufig und soll flüssig in ein TextField übertragen werden. Und da weichen die isolierten Laborergebnisse erheblich vom Feldtest ab - im Feldtest sollte man in einem realistischen Szenario messen. Und da halte ich es für realistischer, dass das TextField die Werte auch anzeigt.

Kurz: Bindings sind isoliert betrachtet erheblich langsamer als direkter Zugriff, aber im Fall von TextFields, die ihre Werte anzeigen, liegt der Laufzeitunterschied im Promillebereich. Deshalb bieten andere Stellen vermutlich größeres Optimierungspotenzial.

Original von obb
Und dass ich in Zukunft setValue forKey, welchem ich auch Trägheit zugetraut hätte in einem ganz anderen Licht sehe.

Das hat mich übrigens auch ziemlich überrascht.