OOP sucks!

[th.]

Hey,
habe im Auftrag vom WM-Team eine Game-Engine programmiert, klein, übersichtlich, nach objektorintierten Prinzipien. Dabei wurde jedoch ziemlich schnell klar, dass das Ganze zu langsam wird. Also alles über Bord geworfen, was an Struktur drin war, alles auf _root gepackt, die meisten Funktinen dupliziert und direkt in den Code gepackt und siehe da, 50% bessere Performance. Warum gibt es da so einen krassen Unterschied? Auf jeden Fall habe ich jetzt ein echtes Problem, wenn das Teil mal gewartete werden muss.

Gruß,
Thorsten

[flory]

wat soll man da sagen?
ich habe auch gerade ein (Iso-)Spiel programmiert, auch (relativ) streng objektorientiert
und bin mit der Performance sehr zufrieden.
hier isset:
http://www.duschdas.de/unterhaltung/...el/default.asp

Ich wüsste gar nicht, wie ich das ohne OOP hätte realisieren sollen.
Es gibt halt ein paar Dinge von denen man die Finger lassen sollte, wenn
es um Performance geht, z.B. FLEM/Asbroadcatser.
Es ist halt eine Frage, wie man an die Dinge rangeht,
for..in Loops zum Bsp. sind um einiges schneller als normale Schleifen,
machen aber nur mit OOP Sinn.
Ein Problem mit Flash&OOP ist sicher die Geschichte, das verschachtelte
Objekte Punkt für Punkt evaluiert werden,
aber die kann man ja zur Not am Ende mit eval bzw. set wieder flott machen.

Florian

[th.]

Hi Flory,
natürlich macht OOP in Projekten, in denen es nicht so auf auf Performance ankommt. Bei meinen ersten Iso-Game hatte ich da auch keine Probleme...
Hier gibt es aber viel mehr Tiles, KI für mehrere Gegner usw.

Gruß,
Thorsten

[flory]

bleibt dabei, OOP und Performance schliessen sich nicht aus,
ist nur ne Frage der Optimierung und der Effizienz der Algorithmen.
Ich hab ja auch schon ein paar Spiele gebaut - man muss sich halt vorher
Gedanken machen.
Glaub mir, die scrollende Iso-Landschaft und die Gegner sind auch nicht ganz ohne.
Wenn man weiss, wo die Nadelöhrs liegen und wie man drumrumkommt,
geht das aber.

gruss,
Florian

[th.]

Und selbst wenn alle Flaschenhälse beseitigt sind bringt der Rückbau noch einiges an Performance. Und wenn es wirklich auf jedes Frame ankommt, vergiss OOP, die grundsätzlichn Strukturen können natürlich erhalten bleiben.

Gruß,
Thorsten

[flory]

Der "Rückbau" ist in Flash ja schon drin, die Performancefresser liegen in den
Algorithmen und in den Aufrufen.
Die einzige Schwäche die ich da erkennen kann ist die Sache mit
den Pfaden - jeder Punkt verbrennt zwei Bytecode-Instruktionen mehr.
Hast Du mal Versuche mit set/eval gemacht?

Bei meiner 3D-Engine kam es auch auf jeden Frame an - trotzdem OOP, auch wenn die Methoden in sich extrem optimiert sind.

Aber jedem seine Meinung

Florian

[secp]

ich finde auch das oop eigentlich nicht langsamer ist, die alten f4 funktionen substring() ect. sind halt schneller, aber das hat ja mit oop nicht viel zu tun. Mir kommt prototype = function fast schneller vor als nur function.

OOP !sucks

[hOk]

@th.
Ist ein nettes Game geworden, gefällt mir sehr gut.

@flory
Kannst du mir mal erklären wo der Unterschied ist,
wenn ich mir einen langen Pfad zwischenspeichere
und wenn ich eval oder set verwende.
Ich mach mal ein kleines Beispiel:

PHP-Code:

Car = function () 
{
    this.arrWheels = new Array();
}
Car.prototype.addWheels = function (pNumber)
{
    while (pNumber--) this.arrWheels.push(new Wheel());
}

Wheel = function () {}
Wheel.prototype.explode = function ()
{
    trace('Huups, ein Reifen ist geplatzt!');
}

Knife = function () {}
Knife.prototype.stickWheel = function (pWheel)
{
    pWheel.explode();
}


objCar = new Car();
objCar.addWheels(4);

objWheel = objCar.arrWheels[0];

objKnife = new Knife();
objKnife.stickWheel(objWheel); 


Wo würdest du jetzt mit deinem Performance-Schraubendreher rangehen.
Bzw. hast du ein Beispiel wo set und eval Sinnvoll wären,
würde mich echt interessieren.

viele nette Grüße, Holger

[flory]

Car = function () 
{
    this.arrWheels = new Array();
}
Car.prototype.addWheels = function (pNumber)
{
    while (pNumber--) eval("this.arrWheels.push")(new Wheel());
}
 
Wheel = function () {}
Wheel.prototype.explode = function ()
{
    trace('Huups, ein Reifen ist geplatzt!');
}
 
Knife = function () {}
Knife.prototype.stickWheel = function (pWheel)
{
    eval("pWheel.explode")();
}
 
 
objCar = new Car();
eval("objCar.addWheels")(4);
 
objWheel = eval("objCar.arrWheels")[0];
 
objKnife = new Knife();
eval("objKnife.stickWheel")(objWheel); 

an deinem Beispiel kann aber man nicht so viel rumschrauben, weil ja hauptsächlich Strukturen
definiert werden und nicht viel an Berechnungen/Logik passiert.
Die Geschichte mit eval() wurde hier im OOP-Bereich glaub ich schon ein paarmal erklärt.
Bei Flash5 konnte man eval noch auf die rechte Seite setzen (eval("this.prop.prop")=xyz, in MX
muss man das über set machen (set("this.prop.prop",xyz). Letzteres funktioniert aber nur, wenn die Properties vorher schonmal "ordentlich" definiert wurden (z.B. im Konstruktor this.prop.prop=initval).
Wenn man sich ein bischen mit Flash-Bytecode auseinandersetzt, versteht man, warum das
so ist - Stichwort setmember vs. setvariable.
Wenn´s Dich interessiert, spiel mal ein bischen rum und dekompilier den Code in Flasm.

Viele interessante Einsichten wünscht
Florian

[bokel]

th,
du hast es eben einfach nicht drauf

Ne Quatsch,
wenn ein Funktionsaufruf schon
uber 50 % Performance kostet,
dann ist es halt schwierig mit OOP.

function test(){
    x = x + 2;
}
 
t = getTimer();
for(i=0; i<1000; i++){
    test();
}
trace(getTimer() - t);
 
t = getTimer();
for(i=0; i<1000; i++){
    x = x + 2;
}
trace(getTimer() - t); 

output
107
47


Aber für den Entwurf und für nicht so
rechenintensive Sachen möchte ich es nicht
mehr missen. Optimieren kann man dann
anschliessend.

Denn nach einer alten Regel verbringt ein Programm
90% der Zeit in 10% des Codes, und dort muss
man optimieren, der Rest kann sauber bleiben.

mfg r.

[flory]

also: functions suck

florian

[secp]

hmm hab mal getestet, th. hat doch recht, oder?

function test(){
        x = x + 2;
}
 
function tObj(){
    this.x = 0;
}
tObj.prototype.test = function(){
    this.x = this.x + 2;
}
 
obj = new tObj();
t = getTimer();
for(i=0; i<1000; i++){
        obj.test();
}
trace(getTimer() - t);
 
 
t = getTimer();
for(i=0; i<1000; i++){
        test();
}
trace(getTimer() - t);
 
 
 
t = getTimer();
for(i=0; i<1000; i++){
        x = x + 2;
}
trace(getTimer() - t); 

ausgabe:
101
87
40

[flory]

mit

tObj.prototype.test = function(){
        set("this.x",eval("this.x") + 2);      
} 

komme ich auf 99 zu 86. ist zwar langsamer, aber die 15% relativieren sich auch, weil man normalerweise nicht ausschlieslich properties setzt, sondern auch mal lokale Variablen benutzt (oder sollte).

Der Vergleich mit dem letzten Beispiel ist natürlich irgendwo Banane - für jede Addition extra eine Funktion aufzurufen ist logischerweise langsamer, als einfach zwei und zwei zusammenzuzählen. Aber im echten Leben macht man das ja auch nicht.

Im echten Leben sieht es dann doch eher so aus:

function Class(x) {
  this.x=x; 
}
 
Class.prototype.count1000=function() {
  var x=eval("this.x");
  for (var i=1000;i --; ) {
      x+=2;
  }
  set("this.x",x);
}
 
t = getTimer();
obj=new Class(12);
obj.count1000();
trace(getTimer() - t);
 
// - - - - -
 
t = getTimer();
for(i=0; i<1000; i++){
        x = x + 2;
}
trace(getTimer() - t); 

output:
18
30

OOP, trotzdem fast doppelt so schnell
in dem Fall ging es natürlich auch ohne set und eval ohne grossen Performance-Verlust

[secp]

ja wenn man den pfad auch noch zwischenspeichert ist es genauso schnell wie normale funktionen, bei deiner syntax stimmt x nicht mehr

tObj.prototype.test = function(){
      set("x",eval("x") + 2);
}
 
obj = new tObj();
f = obj.test;
t = getTimer();
for(i=0; i<1000; i++){
       f();
}
trace("x : " + x + ", " +(getTimer() - t)); 

[flory]

ojeoje, wat soll dat dann?
schau dir deinen code nochmal an...

Florian