Ressourcen schonen

@kresse

Es mag ja von theoretischer Erkenntnis sein zu wissen, was das genau an dieser Stelle kostet. Nur, und darauf will mattik heraus: Niemand will Werte in Views setzen, die nicht angezeigt werden. Das Anzeigen dauert aber exorbitant länger als das Setzen und zwar völlig unabhängig davon, wie man es macht:

Ergo: Für die Realität ist dieser Unterschied völlig unmaßgeblich. Es sei denn, man möchte wirklich Werte in ein View setzen, die nicht angezeigt werden. Da habe ich allerdings einen Code, der das sagenhaft schnell erledigt:
Das meine ich ja: Du kannst mit dieser Zahl nichts anfangen, weil du nicht weißt, welchen Anteil sie am Gesamtaufwand hat. Beträgt der Restaufwand 1 Sekunde, so ist jedes eingesparte Zehntel Gold wert. Beträgt wie hier der Gesamtaufwand eine halbe Stunde, so sind die 6 Sekunden völlig lächerlich und die falsche Stelle zum Optimieren. Oder anders gesagt:

Vorzeitige Optimierung ist eine Klassenmethode von NSKristallkugel.

Na also,

eigentlich sind wir uns ja alle einig.

1. Bindings sind etwas langsamer als direkter Zugriff

2. Ist das normalerweise nicht relevant, weil das was danach kommt noch viel schlimmer ist

Das hat mich übrigens auch ziemlich überrascht.

Mich auch

Original von kressevadder
Na also,

eigentlich sind wir uns ja alle einig.

1. Bindings sind etwas langsamer als direkter Zugriff

2. Ist das normalerweise nicht relevant, weil das was danach kommt noch viel schlimmer ist

Das hat mich übrigens auch ziemlich überrascht.

Mich auch

Jepp. Und in dem "normalerweise" liegt die Kristallkugel. Ds kannst du nämlich erst wissen (aka messen), wenn dein Programm läuft.

Natürlich: Umgekehrt gewinnt man mit der Zeit Erfahrungen. Und eine der Erfahrungen lautet: Wenn irgendetwas mit Zeichnen gemacht wird, kannst du erst einmal ganz lange alles andere vergessen, was in deinem Programm geschieht, seien es Bindings, seien es Dispatches … Alles uninteressant.

Übrigens kann man mit beiden hier schon angesprochenen Problemfeldern sehr gut optimiert umgehen, ohne auf die Technologien zu verzichten. Bei Bindings wirst du etwa ein Laufzeitproblem erst dann bemerken, wenn du ein to-many in einer Schleife abackerst. Dann bietet es sich aber an, das Binding einfach aufzulösen und auf dem Original-Objekt zu arbeiten. Dann hast du anstelle von 1000 Mal Faktor 6,7 einfach nur einmal Faktor 6,7 und 999 Mal Faktor 1. Das ergibt dann insgesamt Faktor 1,0057, was doch schon ganz anders aussieht.

Das meinte ich unter anderem mit: Es gibt intelligentere Optimierungsideen anstelle des Verzichtes auf Technologien.