Performancemythen?

DEvent schrieb:

Aber genau darum ging es mir nicht. Ich sagte nicht: "simpler Code ist schnell", sondern "einfacher Code ist schnell". Wenn der Code klar strukturiert ist, Abläufe klar erkennbar sind und auch schnell zu ersehen ist welcher Teil des Codes was tut, dann ist er meist auch schnell. Oder anders gesagt: ein sauberes Design macht mehr aus als die ganzen low-level hacks.

Leider hat die Strukturiertheit und Ubersichtlichkeit gar nichts mit der Geschwindigkeit des Codes zu tun. Also liegst du schon mal 2 mal falsch.

du hast noch nie an einem mittelgroßen softwareprojekt gearbeitet oder?

Gregor

DEvent schrieb:

Leider hat die Strukturiertheit und Ubersichtlichkeit gar nichts mit der Geschwindigkeit des Codes zu tun. Also liegst du schon mal 2 mal falsch.

Doch, hat es. ...und zwar, wenn Du Dir die Frage stellst, wer den Code geschrieben hat. Dann wirst Du nämlich feststellen, dass Leute mit Erfahrung in der Programmierung, als auch entsprechendem Wissen im jeweiligen Themenbereich, die benötigten Voraussetzungen haben, qualitativ hochwertigen Code zu schreiben. ...und zwar in allen Aspekten. Wer diese Voraussetzungen nicht hat, kann nicht mit einer gleichartigen Systematik an das Projekt herangehen und entsprechend wird da schlechterer Code herauskommen.

Ponto

CStoll schrieb:

@list: Vielleicht sollte doch mal jemand, der den Standard vorliegen hat, die genauen Performance-Anforderungen der list-Methoden nachschlagen (ich habe hier nur Sekundär-Literatur und die liefert widersprüchliche Angaben). Ich kann mir zumindest drei Varianten vorstellen, wie splice() und size() zusammenarbeiten können:

die libstdc++-Variante: splice() verbiegt nur die Zeiger und size() zählt jedes Mal durch (ergibt O(n) für size()).

die MSVC-Variante: splice() aktualisiert die Größenangabe (ergibt O(n) für splice().

lazy evaluation: splice() markiert die Größenwerte als ungültig und size() zählt nach, wenn notwendig (ergibt O(n) im worst case für size() - im Mittel haben beide vermutlich konstante Laufzeit)

Alle drei Varianten sind nach Standard möglich.

frenki schrieb:

Ja, nee, is klaaar. Darum gibt es vermutlich auch soviele CPU-Limitierte Games.

nun, die hauptrechenleistung bei spielen geht wohl auf die grafik zurück. die wird zuallererst mal auf der gpu nich auf der cpu berechnet. desweiteren sind grafikberechnungen allesamt nur implementierungen von mathematischen algorithmen. also entweder entwickelt man neue algorithmen oder neue gpus. mit ++i vs i++ kannst du da absolut nichts rausholen.

ps: computerspiele sind scheiße

Gregor

dieser thread schrieb:

nun, die hauptrechenleistung bei spielen geht wohl auf die grafik zurück. die wird zuallererst mal auf der gpu nich auf der cpu berechnet. desweiteren sind grafikberechnungen allesamt nur implementierungen von mathematischen algorithmen. also entweder entwickelt man neue algorithmen oder neue gpus. mit ++i vs i++ kannst du da absolut nichts rausholen.

Vielleicht spielt DEvent am Computer eher Schach und eher weniger Killerspiele. ...wer weiß.

this-*gt*that

dieser thread schrieb:

nun, die hauptrechenleistung bei spielen geht wohl auf die grafik zurück.

Eher nicht. Die meiste Rechenleistung wird meistens durch die Logik (KI etc.) verbraten.

Jester

Gregor schrieb:

Doch, hat es. ...und zwar, wenn Du Dir die Frage stellst, wer den Code geschrieben hat. Dann wirst Du nämlich feststellen, dass Leute mit Erfahrung in der Programmierung, als auch entsprechendem Wissen im jeweiligen Themenbereich, die benötigten Voraussetzungen haben, qualitativ hochwertigen Code zu schreiben. ...und zwar in allen Aspekten. Wer diese Voraussetzungen nicht hat, kann nicht mit einer gleichartigen Systematik an das Projekt herangehen und entsprechend wird da schlechterer Code herauskommen.

Danke, endlich jemand der versteht was ich meine. Wie gesagt: ich will einfachen Code, nicht simplen oder stupiden Code. Man kann auch komplexe Algorithmen klar und einfach implementieren.

C ist schneller als C++. Ende.

asc

Kenner des Codes schrieb:

C ist schneller als C++. Ende.

Von der Reinen Aussage her ja, genauso wie Assembler schneller als C ist.

Aber in der Praxis gibt es mehr als nur einen reinen Sprachvergleich:

a) Ist der Code noch so gut überschaubar das sich nicht Fehler und Codeduplikate sowie Performancefallen mehren? Zumeist liegt der Vorteil von C++ gegenüber C an der besseren Strukturierung (Wobei vieles an Programmiererfahrung liegt).

b) Der Code mag noch so schnell sein, die Umsetzung muss in der Regel gegen einen Gewissen Zeitdruck erfolgen. Performance ist nicht Alles, sonst würde es keine Sprachen wie Java und C# geben. Man muss immer gewisse Kompromisse eingehen.

cu André

Mr. N

asc schrieb:

Kenner des Codes schrieb:

C ist schneller als C++. Ende.

Von der Reinen Aussage her ja, genauso wie Assembler schneller als C ist.

Beides Blödsinn.

Xin

Cpt. Nukem schrieb:

Man liest ja hier öfters OOP ist langsamer als ohne OOP oder ++iter statt iter++.

Dazu vielleicht mal etwas Klartext:

int & int::operator ++() // ++i
{
  value = value + 1;
  return this;
}

int int::operator ++( int ) // i++
{
  int temp = value;
  value = value + 1;
  return temp;
}

Du siehst, die Postfix-Variante benötigt ein temporäres Objekt und hat daher mehr Aufwand.
Das Objekt ist in diesem Fall (int) kein erwähnenswertes Problem. Ergo auch kein Problem, da der Compiler das hier ausgleichen kann:

int & int::operator ++() // ++i
{
  value = value + 1;
  returncode = value;
}

int int::operator ++( int ) // i++
{
  returncode = value;
  value = value + 1;
}

Hier werden Objekte kopiert, was bei Integers durch die CPU problemlos erledigt werden kann. Nehmen wir an, es gibt ein Objekt Bitmap, dass mit ++ die Transparenz erhöht. Nun haben wir eine 2MPix Bitmap, das sind 8MB Daten.
Rufst Du ++i auf, wird die Bitmap verändert und stellt auch das Ergebnis dar. Rufst Du i++ auf, wird ein Temporäres Objekt erzeugt, 8MB Daten kopiert und modifiziert, um dann wieder verworfen zu werden.

++i spart - in der Regel - das Erzeugen und Zerstören eines temporären Objektes und die Verwendung von ++i ist definitiv kein Performance-Mythos.

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Mr. N

Xin schrieb:

Cpt. Nukem schrieb:

Man liest ja hier öfters OOP ist langsamer als ohne OOP oder ++iter statt iter++.

Dazu vielleicht mal etwas Klartext:
int & int::operator ++() // ++i
{
  value = value + 1;
  return this;
}

int int::operator ++( int ) // i++
{
  int temp = value;
  value = value + 1;
  return temp;
}
Du siehst, die Postfix-Variante benötigt ein temporäres Objekt und hat daher mehr Aufwand.
Das Objekt ist in diesem Fall (int) kein erwähnenswertes Problem. Ergo auch kein Problem, da der Compiler das hier ausgleichen kann:
int & int::operator ++() // ++i
{
  value = value + 1;
  returncode = value;
}

int int::operator ++( int ) // i++
{
  returncode = value;
  value = value + 1;
}
Hier werden Objekte kopiert, was bei Integers durch die CPU problemlos erledigt werden kann. Nehmen wir an, es gibt ein Objekt Bitmap, dass mit ++ die Transparenz erhöht. Nun haben wir eine 2MPix Bitmap, das sind 8MB Daten.
Rufst Du ++i auf, wird die Bitmap verändert und stellt auch das Ergebnis dar. Rufst Du i++ auf, wird ein Temporäres Objekt erzeugt, 8MB Daten kopiert und modifiziert, um dann wieder verworfen zu werden.

++i spart - in der Regel - das Erzeugen und Zerstören eines temporären Objektes und die Verwendung von ++i ist definitiv kein Performance-Mythos.

Das stimmt soweit natürlich alles.

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Shade Of Mine

Mr. N schrieb:

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

weil OOP ist evil...

Irgendwann werden die Leute schon verstehen dass ob OOP oder sonstwas - nur eine Art Probleme zu lösen ist. Man kann Probleme auf viele Arten lösen - mal mag die eine eleganter sein als die andere - aber mit Performance hat das erstmal nichts zu tun.

Bestes Beispiel sind virtuelle Funktionen. Klar kosten sie mehr als eine normale Funktion - aber dafür hat man eine Fallunterscheidung die man ja nicht einfach ignorieren kann. Egal wie ich das Problem nun angehe - ich brauche diese Fallunterscheidung. Sei es eine Jump Table, ein if, ein switch, virtuelle Funktionen oder höher stehende Magie - ich habe kosten für diese Unterscheidung.

asc schrieb:

Kenner des Codes schrieb:

C ist schneller als C++. Ende.

Von der Reinen Aussage her ja, genauso wie Assembler schneller als C ist.

Aber in der Praxis gibt es mehr als nur einen reinen Sprachvergleich:

a) Ist der Code noch so gut überschaubar das sich nicht Fehler und Codeduplikate sowie Performancefallen mehren? Zumeist liegt der Vorteil von C++ gegenüber C an der besseren Strukturierung (Wobei vieles an Programmiererfahrung liegt).
**
b) Der Code mag noch so schnell sein, die Umsetzung muss in der Regel gegen einen Gewissen Zeitdruck erfolgen. Performance ist nicht Alles, sonst würde es keine Sprachen wie Java und C# geben. Man muss immer gewisse Kompromisse eingehen.**

cu André

LOL das mag ja richtig sein was du unter b) gesagt hast, aber ging es grad net um die reine Performance .

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Ich versteh zwar den Zusammenhang nicht, dass etwas langsamer ist, weil es eine Technik ist. Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Man kann natürlich noch weiter gehen und sagen, dass Funktionsaufrufe Zeit brauchen, darum sollte man alles direkt hinschreiben. Macht wohl keiner.

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Mr. N

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Falsch!

tntnet

Mr. N schrieb:

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Falsch!

Richtig! Also Richtig, daß es Falsch ist . Ich wollte nur eine kleine Erläuterung dazu fügen. Ein Konstruktor, der inline ist und nichts macht ist performancetechnisch kostenlos. Daher ist es einfach egal, ob ich ein Objekt erzeuge und damit eine Funktion aufrufe oder direkt eine Funktion aufrufe. Und hier gilt das gleiche, wie Shade Of Mine über virtuelle Methodenaufrufe gesagt hat. Ein Aufruf einer Methodenfunktion erfüllt einen Zweck. Und um diesen Zweck zu realisieren, ist ein Objekt eine mögliche Lösungsvariante, die nicht unbedingt teurer ist, als eine nicht-OOP Technik.

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. Und dann schau mal, welche Datenstruktur schneller war. Die Liste ist in dem Anwendungsfall dem Array haushoch überlegen. Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Hier kommt doch gleich ein Vorteil von C++ gegenüber C zum Tragen. Bei so einem Anwendungsfall überlege ich mir in C 2 mal, ob ich den Aufwand, eine Liste zu programmieren auf mich nehme. In C++ schreibe ich einfach std::list statt std::vector. Daher bin ich bestrebt, in C++ die effizientere Lösung zu realisieren.

hustbaer

Wer nicht glaubt dass es CPU limitierte Games gibt soll mal X³ spielen...

Xin

Mr. N schrieb:

Xin schrieb:

...

Das stimmt soweit natürlich alles.

Cool. :->

Mr. N schrieb:

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Ich weiß nicht, was Du hier konkret als Unfug bezeichnest, entsprechend kann ich Dir auch nichts erläutern oder Dir sagen, wie ich darauf komme, es hier zu schreiben.

Zwei Dinge kann ich jedoch beantworten. Erstens: Ich schreibe keinen Unfug und zweitens: ich schreibe hier nicht, um Erwartungen zu entsprechen.

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird. Wenn das nicht bekannt ist, so sollten wenigstens die sich daraus ergebenen Vor- und Nachteile sollten bekannt sein. Die habe ich in dem Bereich aufgeführt, den Du als Unfug bezeichnest.

Cpt. Nukem schrieb:

Ich versteh zwar den Zusammenhang nicht, dass etwas langsamer ist, weil es eine Technik ist.

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

Das macht man, um Entscheidungen nicht treffen zu müssen.
Die Umsetzung von OOP in C++ ist also auch eine Technik, die hilft bei komplizierten Fragestellungen den Überblick zu behalten und notwendige Fragen in grundsätzlich nur 3 Schritten zu beantworten. Das hilft Zeit zu sparen, denn ein Algorithmus, der fragt, bräuchte mehr Schritte.

Nutzt man OOP bei Funktionsrufen, wo keine Entscheidungen zu treffen sind, so verliert man Zeit. Nutzt man OOP bei Funktionen, die objektabhängig sind, spart man Zeit oder viel Aufwand und erhält übersichtlichen Code. Man verliert in dem Fall aber keine Zeit, weil die Entscheidung muss so oder so getroffen werden. Und in der Regel wird sie schlechter implementiert, als es C++ macht. In dem Fall ist OOP mit C++ schneller.
Man muss OOP sinnvoll und bewußt einsetzen.

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Richtig. Hier verliert man bei ungeschickter Programmierung (z.B. i++ statt ++i) unnötig Zeit.

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

Macht man sich vom Objekttyp abhängig, programmiert das Ganze also objektorientiert statt sich auf die aktuelle Sichtweise auf das Objekt zu konzentrieren (klassenorientiert), dann wird der Funktionsaufruf dynamisch und zur Laufzeit ermittelt.

Cpt. Nukem schrieb:

Man kann natürlich noch weiter gehen und sagen, dass Funktionsaufrufe Zeit brauchen, darum sollte man alles direkt hinschreiben. Macht wohl keiner.

Würde auch keinen Sinn machen, da nicht ohne Funktionsaufrufe kaum etwas programmieren kann. Um z.B. Bäume zu durchwandern, müsste man sich in dem Fall den Stack selbstbauen, weil man rekursive Algorithmen nicht direkt hinschreiben kann. Man spart in dem Fall also auch nichts.

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.
Das ist aber sehr programmabhängig, die Zahlen sind also bestenfalls wage Anhaltspunkte, ich habe sie aber schon in verschiedenen Büchern zu dem Thema gesehen. Es liegt auch nicht vorrangig an OOP, sondern an der Tatsache, dass C++ Compiler aufwendiger sind als C-Compiler, entsprechend auch die Optimierung aufwendiger wird. Doch auch die C++ Compiler werden immer besser. Die Qualität der C++-Übersetzungen wird sich mehr und mehr an C annähern, genauso wie sich C an Assembler weiter annähern wird. Trotzdem kann man davon ausgehen, dass C++-Programme langsamer bleiben als C-Programme, weil irgendeine Ungeschicktheit findet sich vermutlich in jedem C++-Programm.

Die Zahlen sind alt, die Differenz sollte inzwischen kleiner sein, aber selbst würde ein Programm 10x langsamer laufen, hilft C++ deutlich, Programme übersichtlicher und damit fehlerfreier zu gestalten. Ein Programm, dass nach 10 Stunden zum Ziel kommt ist effizienter als ein Programm, das nach 1 Stunde ein falsches Ergebnis liefert.

tntnet schrieb:

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. [...] Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Arbeitest Du eigentlich im Marketing-Bereich?

(Oder) gilt es heute wirklich schon als Diskussionsargument, wenn man die Aussage des Vorredners wiederholt und behauptet, man würde ihm so widersprechen?

Lies doch nochmal nach, wogegen Du widersprichst:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.