IF-Anweisungen oder Switch-Case?

[Torsten]

Hallo HTML'er!

Ich hab mal wieder eine Frage.
Was wäre günstiger auch von der Performance her?
Viele Fallunterscheidungen durch if-Anweisungen zu untescheiden oder ein Switch-Case Block zu programmieren?

Allso:

if(...){...}
if(...){...}
...
oder

switch(...) {
case "..."
...
break;
case "..."
...
break;
...

Gibt es eine bestimmte Anzahl von Fällen, ab die sich Switch Case lohnt oder ist das egal und liegt nur im Auge des Programmierers?

MFG
Torsten

[Danny]

Moin!

Von der Performance her kann ich mir nicht vorstellen, dass es überhaupt einen Unterschied macht...

Switch dient mehr der Übersichtlichkeit wg. der linearen Codierung bei vielen ähnlichen Bedingungen, z.B. wenn eine einzige Variable auf eine Folge unterschiedlicher Werte zu testen und danach entsprechend zu verzweigen ist.

freundlichen Gruß
Danny

[Torsten]

Hallo Danny,

Switch dient mehr der Übersichtlichkeit wg. der linearen Codierung bei vielen ähnlichen Bedingungen, z.B. wenn eine einzige Variable auf eine Folge unterschiedlicher Werte zu testen und danach entsprechend zu verzweigen ist.

Ok, das wäre der Fall bei mir. Da werd ich der Übersichtlichkeit wegen meine If-Anweisungen in Switch umwandeln.

Danke!

MFG
Torsten

[Tom]

Hello,

Ok, das wäre der Fall bei mir. Da werd ich der Übersichtlichkeit wegen meine If-Anweisungen in Switch umwandeln.

Vielleicht kannst Du Deine Entscheidung auch mit einem Index beantworten.
Wenn das Kriterium selbst ein Index in eine Liste darstellt, dann ist das in "normalen" Hochsprachen am schnellsten. Allerdings untersützt PHP nicht wirklich eigene Datenstrukturen, sodass die Suche in einem "Array" wahrscheinlich interne auch wieder eine Menge Vergleiche nötig machen wird. Nur Du siehst sie dann nicht in Deinem Quellcode.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Torsten]

Danke für die zahlreiche Hilfe!!!

MFG
Torsten

[Struppi]

Ich hab mal wieder eine Frage.
Was wäre günstiger auch von der Performance her?
Viele Fallunterscheidungen durch if-Anweisungen zu untescheiden oder ein Switch-Case Block zu programmieren?

switch-case ist eine sehr teure Variante (zumindest war das früher mal so) und ist  nur in seltenen Fällen nötig. Je nach dem was du vorhast, kann u.U. ein Objekt wesentlich schneller sein.

z.b.
function func_a(){alert('func_a');}
function func_b(){alert('func_b');}

var action = new Object();

action['do_A'] = func_a;
action['do_B'] = func_b;

function Action(a)
{
actiona;
}

Action('do_A');

Keine if Anweisung kein vergleich ein direkter Zugriff auf eine Funktionsreferenz.

Aber wie gesagt es kommt drauf an was du machst
Struppi.

[Torsten]

Grüß dich

Aber wie gesagt es kommt drauf an was du machst

Ich Unterscheide bei der Auswahl einer Select-Box nach dem Wert einer schon vorher ausgewählten Select-Box:
...
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "a")
{
   ...
}
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "b")
{
   ...
}
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "c")
{
   ...
}
...

Ich hoffe ich konnte mich verständlich ausdrücken.
Und jetzt bin ich dabei dies in Switch umzuwandeln. Oder gibt es dafür noch eine bessere Lösung?

MFG
Torsten

[Danny]

Hi,

eins = document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value;

if     (eins == "a") {

}
elseif (eins == "b") {

}
elseif (eins == "c") {

}

MfG
Danny

[Torsten]

Danke für die Verbesserungsvorschläge.
function resetToDefault(a, b)
{
   for (var i = 0; i < document.forms[a].elements[b].length; i++)
      {
      if ( document.forms[a].elements[b].options[i].defaultSelected == true)
         document.forms[a].elements[b].options[i].selected = true;
      }
}

In den einzellnen Blöcken soll dann lediglich eine Folge-Box resettet und eingeblendet werden, also:

...
{
   resetToDefault("forma", "auswahlaeins");
   document.getElementById("AuswahlaEinsID").style.display="block";
}
...

Ist da Switch die beste Lösung oder optimierte If-Anweisungen?

MFG
Torsen

[Struppi]

In den einzellnen Blöcken soll dann lediglich eine Folge-Box resettet und eingeblendet werden, also:

...
{
   resetToDefault("forma", "auswahlaeins");
   document.getElementById("AuswahlaEinsID").style.display="block";
}
...

Ist da Switch die beste Lösung oder optimierte If-Anweisungen?

weder noch. Ich vermute - deine Salamitaktik macht es nicht einfach zu durchschauen was passieren soll - das du mit einem Paramedter besser fährst. sowei ich das jetzt sehe hast du ein select und je nach value wird ein Beriech zurückgesetzt.

Erstmal kannst du eine vereinfachunf vornhemen, wenn du der entsprechenden Funktion den Wert direkt übermittelst:

<select onchange = "funktion_1(this.options[this.selectedIndex].value] );">
....
</select>

und in der funktion willst du das resetToDefault aufrufen und etwas anzeigen:

function funktion_1(wert)
{
if(!wert) return;
resetToDefault("form" + wert, "auswahl" + wert + "eins");
document.getElementById("Auswahl" + wert + "EinsID").style.display="block";
}

wie du siehst ohne switch oder if.

Wobei ich mir nicht sicher bin, ob die 'eins' nicht auch ein Parameter sein kann. Aber wie gesagt mit den Brucjstücken läßt sich nur schwer genaues sagen.

Struppi.

[Torsten]

Ich habe mehrere  Select-Boxen.
Eine davon muß je nach Wert einer Vorherigen entscheiden, wie die nächste Select-Box ausschauen muß.

Hab das jetzt erst mal so gemacht:

function GoProduct(p)
     {
      product = p;
      ...
      if ( product != "[ select ! ]" )
      {

var Konfiguration = document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value;
       switch(Konfiguration)
       {
        case "A":
         resetToDefault("formc", "auswahlca");
         document.getElementById("Ca").style.display="block";
         break;
        case "B":
         resetToDefault("formc", "auswahlcpuscb");
         document.getElementById("Cb").style.display="block";
         break;
        case "C":
         resetToDefault("formc", "auswahlcc");
         document.getElementById("Cc").style.display="block";
         break;
        ...       }
      }
      else
      {
       ...
      }
           }

Ich hoffe das hilft weiter. Ist dies die beste Variante?

MFG
Torsten

[Struppi]

Hab das jetzt erst mal so gemacht:

function GoProduct(p)
     {
      product = p;

Ist p der value der selectBox?

...
      if ( product != "[ select ! ]" )
      {

var Konfiguration = document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value;
       switch(Konfiguration)
       {
        case "A":
         resetToDefault("formc", "auswahlca");
         document.getElementById("Ca").style.display="block";
         break;
        case "B":
         resetToDefault("formc", "auswahlcpuscb");
         document.getElementById("Cb").style.display="block";
         break;
        case "C":
         resetToDefault("formc", "auswahlcc");
         document.getElementById("Cc").style.display="block";
         break;

das kannst du enorm vereinfachen:

var Konfiguration = document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value.toLowerCase();

resetToDefault("form" + Konfiguration, "auswahlca");
document.getElementById("C" + Konfiguration).style.display="block";

wenn du die Elemente nach dem gleichen Schema benennst.

Struppi.

[Torsten]

Ist p der value der selectBox?

ja, ist er.

das kannst du enorm vereinfachen:

var Konfiguration = document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value.toLowerCase();

resetToDefault("form" + Konfiguration, "auswahlca");
document.getElementById("C" + Konfiguration).style.display="block";

wenn du die Elemente nach dem gleichen Schema benennst.Die Elemente sind alle nach dem gleichen Schema benannt.

Werde das mal versuchen.
resetToDefault("form" + Konfiguration, "auswahlca");
document.getElementById("C" + Konfiguration).style.display="block";

Und das wäre alles? Oder wäre das ein spezieller case?

MFG
Torsten

[Struppi]

Hallo Torsten

Ist p der value der selectBox?

ja, ist er.

Ich vermute mla hier wäre noch mehr verienfachung möglich, aber wie gesagt ohne genauer Infos läßt sich das nur schwer sagen.

Und das wäre alles? Oder wäre das ein spezieller case?

nein das wäre alles ohne case und ohne if.

Nur musst du die Elemente richtig bennen oder noch ein paar Änderungen einbauen, da du offensichtlich die id's mal in der Form 'bezeichnunga' und 'bezeichnungA' vergibst, also entweder immer kleine Bucjstaben, oder du musst in den entsprechenden aufrufen noch ein toUpperCase bzw. toLowerCase einbauen.

Struppi.

[Struppi]

if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "a")

{
   ...
}
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "b")
{
   ...
}
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "c")
{
   ...
}
...

Na, das ist schon mal per se umständlich.

var val = document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value;

if(val == 'a')
else if( val == 'b')
else if (val == 'c')

aber wie gesagt es kommt daruaf an, was passieren soll in den verschiedenen Blöcken.

Ich hoffe ich konnte mich verständlich ausdrücken.
Und jetzt bin ich dabei dies in Switch umzuwandeln. Oder gibt es dafür noch eine bessere Lösung?

MFG
Torsten

Struppi.

[wahsaga]

hi,

if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "a")
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "b")
if(document.getElementById("Eins").options[document.getElementById("Eins").selectedIndex].value == "c")

achtung! getElement(s)By... sind "teure" funktionen, sie kosten performance, weil immer wieder der dokumentbaum durchsucht werden muss, bei jedem aufruf.

viel "günstiger" wäre hier:

var obj = document.getElementById("Eins");
if(obj.options[obj.selectedIndex].value == "a")
...

gruß,
wahsaga

[Torsten]

Ok, danke für den Tip, werde mein Script entsprechend ändern.
MFG
Torsten

[Christoph Zurnieden]

Hi,

nachdem die werten Kollegen nun erfolgreich festgestellt haben, das es wohl wahrscheinlich am Algorithmus selber lag (es liegt in 99% der Fälle daran. Der Rest lohnt sich auch nur, wenn sich damit die Verkaufszahlen erhöhen lassen und/oder der Code besonders elegant ist.) möchte ich doch einmal kurz auf den Unterschied zwischen switch() und if/else Konstrukten eingehen.

Wenn der Compiler/Interpreter gut ist, tut sich bei beiden nicht viel auf höchster Optimierungsstufe. Allerdings ist mir kein Compiler/Interpreter bekannt, der tatsächlich von sich aus die beste Methode wählt. (Beim neuem Perl habe ich aber noch nicht in den Code geschaut ;-)

Der Unterschied liegt bei den meisten mir bekannten Interpretern/Compilern darin, das ein switch() als vollständiger binärer Baum oder als Heap aufgebaut wird und ein if/else Konstrukt dagegen der Reihe nach abgeklappert wird.

Technisch gibt es eine Beschränkung aber nur dahingehend, das die Vergleichswerte im Vornherein bekannt sein müssen, das ist beim if/else Konstrukt nicht der Fall. So etwas wie if(function_1() == function_2()) geht im switch() nicht. Sonst ist alles im switch erlaubt, aber aus Simplizitätsgründen sind meist nur Integerwerte drin.

Gibt es eine bestimmte Anzahl von Fällen, ab die sich Switch Case lohnt oder ist das egal und liegt nur im Auge des Programmierers?

Ja, derartige Grenzen bestehen durchaus, aber das erfordert genaue Kenntnis darüber, wie switch() implementiert ist, welche Daten zu erwarten sind und vor allem: ob's jemand bezahlt, das man sich da überall durchwühlt >;->

Aber Scherz beiseite: Schau in der Dokumentation Deiner Sprache nach was in switch() alles erlaubt ist. Das ist dann meist schneller, als if/else. Oder wie aus der Erklärung oben herausziehbar: wenn Du auf eine Reihe (mehr als 3 sollten es schon sein) feststehender Integerwerte testen mußt: nimm einen switch().

so short

Christoph Zurnieden

[Thomas Meinike]

Hallo,

Technisch gibt es eine Beschränkung aber nur dahingehend, das die Vergleichswerte im Vornherein bekannt sein müssen, das ist beim if/else Konstrukt nicht der Fall. So etwas wie if(function_1() == function_2()) geht im switch() nicht.

JavaScript erlaubt auch das:

function function_1(x)
{
  return x*x;
}

function function_2(y)
{
  return y+4;
}

switch(true)
{
  case(function_1(3) == function_2(5)):
  alert("ok");
  break;

// ...
}

BTW: Netscape 4 soll lt. frueheren Threads dabei crashen, was ich mit 4.72 aber nicht reproduzieren kann.

MfG, Thomas

[Christoph Zurnieden]

Hi,

Technisch gibt es eine Beschränkung aber nur dahingehend, das die Vergleichswerte im Vornherein bekannt sein müssen, das ist beim if/else Konstrukt nicht der Fall. So etwas wie if(function_1() == function_2()) geht im switch() nicht.

JavaScript erlaubt auch das:

[...]

switch(true)
{
  case(function_1(3) == function_2(5)):
  alert("ok");
  break;

Gut, switch() hat natürlich auch einen großen Anteil "syntactic sugar", dem kann ich schlecht wiedersprechen ;-)
Obiges Konstrukt läßt sich aber auch schlecht optimieren, das könnte man nur als if/else Konstrukt übersetzen[1]. Sind dahinter noch "normale" Fälle, hätte das zumindest den Vorteil besserer Lesbarkeit. Aber man könnte dann auch nur noch hoffen bzw sich durch den Code quälen, das das auch alles hübsch wegoptimiert wird ;-)

BTW: Netscape 4 soll lt. frueheren Threads dabei crashen, was ich mit 4.72 aber nicht reproduzieren kann.

Ja, die ganz groben Fehler haben sie beim 4er noch repariert, das stimmt. Leider war's das dann auch. Und wirklich alle haben sie auch nicht erwischt.

so short

Christoph Zurnieden

[1] Man könnte den Vergleich der Funktionsrückgaben natürlich auch in einen Baum einbauen, aber das würde zu einer Komplexität führen, die ich nicht handeln müssen möchte ;-)

[Struppi]

Aber Scherz beiseite: Schau in der Dokumentation Deiner Sprache nach was in switch() alles erlaubt ist. Das ist dann meist schneller, als if/else. Oder wie aus der Erklärung oben herausziehbar: wenn Du auf eine Reihe (mehr als 3 sollten es schon sein) feststehender Integerwerte testen mußt: nimm einen switch().

Also ich hab mal einen Benchmark gebaut mit allen drei Möglichkeiten:
http://home.arcor.de/struebig/computer/javascript/test/benchmark.html

Zumindest bei mir ist if am schnellsten und switch deutlich am langsamsten (ich hab hier einen extrem alten Rechner, der bei 1000 durchgängen schon unterschiede zeigt)

Struppi.

[Christoph Zurnieden]

Hi,

Also ich hab mal einen Benchmark gebaut mit allen drei Möglichkeiten:
http://home.arcor.de/struebig/computer/javascript/test/benchmark.html

Aha. Hier ist es ungefähr gleich, switch() ist etwas schneller.
Aber der Versuchsaufbau berücksichtigt auch nicht, ob der Interpreter optimiert.

Vor allem: _welchen_ Browser hast Du benutzt?

Zumindest bei mir ist if am schnellsten und switch deutlich am langsamsten (ich hab hier einen extrem alten Rechner, der bei 1000 durchgängen schon unterschiede zeigt)

Um den gehte es nicht, nur um den Browser.

so short

Christoph Zurnieden

[Daniel Thoma]

Hallo zusammen!

Der benchmark ist in so fern schlecht, als er das Entscheiden zwischen wenigen Fällen sehr oft testet.
Da ergeben sich natürlich kaum nennenswerte Unterschiede. Wenn ein switch (oder der Objektzugriff) Geschwindigkeitsvorteile bringt, dann bei sehr vielen Fällen. Außerdem sollte man die Werte so wählen, dass ein Vergleich relativ viel Zeit benötigt.
Daher noch mal ein anderer Benchmark:

<html>
<head>
<title></title>
<script type="text/javascript">
  function test() {
    var anzahl_werte = prompt("Anzahl Werte", "2000");
    var anzahl_tests = prompt("Anzahl Tests", "1000");
    var werte = new Array();
    for(var i = 0; i < anzahl_werte; i++) {
      werte.push("'w" + Math.floor(Math.random() * 10) + "'");
    }
    var code = "var result = 0;\n"
    code += "wert = " + werte[Math.floor(anzahl_werte / 2)] + ";\n";
    code += "var werte = new Array(" + werte.join(',') + ")\n\n";

code += "var time_if = (new Date()).getTime();\n";
    code += "for(var i = 0; i < " + anzahl_tests + "; i++) {\n";
    for(var i = 0; i < anzahl_werte; i++) {
      if(i != 0) {
        code += "else ";
      }
      code += "if(wert == " + werte[i] + ") {result = " + i + ";}\n";
    }
    code += "}\n";
    code += "time_if = (new Date()).getTime() - time_if;\n\n";

code += "var time_case = (new Date()).getTime();\n";
    code += "for(var i = 0; i < " + anzahl_tests + "; i++) {\n";
    code += "switch(wert) {\n";
    for(var i = 0; i < anzahl_werte; i++) {
      code += "case " + werte[i] + ": result = " + i + "; break;\n";
    }
    code += "}\n";
    code += "}\n";
    code += "time_case = (new Date()).getTime() - time_case;\n\n";

code += "var time_obj = (new Date()).getTime();\n";
    code += "for(var i = 0; i < " + anzahl_tests + "; i++) {\n";
    code += "result = werte[wert];\n"
    code += "}\n";
    code += "time_obj = (new Date()).getTime() - time_obj;\n\n";

code += "alert('IF: ' + time_if + '\n' + 'CASE: ' + time_case + '\n' + 'OBJ: ' + time_obj + '\n');";

var funktion = new Function(code);
    alert("start");
    funktion();
  }
</script>
</head>
<body>
<p>
<input type="button" value="start" onclick="test()" />
</p>
</body>
</html>

Mit dem Mozilla sieht man dann sehr deutlich, dass sowohl if als auch switch in linearer Zeit arbeiten. Allerdings ist switch sehr viel schneller. U.u. wird bei if else konstrukten Rekursion verwendet.

Obj arbeitet in konstanter Zeit, was stark dafür spricht, dass es als Hashtabelle implementiert ist.

Noch eine Frage: Was soll ein Heap bei der Implementierung von switch bringen?

Grüße

Daniel

[Christoph Zurnieden]

Hallo zusammen!

Der benchmark ist in so fern schlecht, als er das Entscheiden zwischen wenigen Fällen sehr oft testet.
Da ergeben sich natürlich kaum nennenswerte Unterschiede. Wenn ein switch (oder der Objektzugriff) Geschwindigkeitsvorteile bringt, dann bei sehr vielen Fällen.

"Sehr viel" ist da relativ. Es fängt schon bei 11 an signifikant zu werden (je nach dem, was da zu vergleichen ist natürlich)

Außerdem sollte man die Werte so wählen, dass ein Vergleich relativ viel Zeit benötigt.

Das verstehe ich nicht. Was soll das bringen?

Daher noch mal ein anderer Benchmark:

[ Auch 'ne schöneIdee! ;-)  ]

Mit dem Mozilla sieht man dann sehr deutlich, dass sowohl if als auch switch in linearer Zeit arbeiten. Allerdings ist switch sehr viel schneller. U.u. wird bei if else konstrukten Rekursion verwendet.

Obj arbeitet in konstanter Zeit, was stark dafür spricht, dass es als Hashtabelle implementiert ist.

Auch einen Baum (wenn auch nicht jeden) kann man in konstanter Zeit durchsuchen.

Aber ein Frage: wenn Du den Mozilla benutzt ist die Wahrscheinlichkeit recht hoch, das Du in den Code schauen kannst. Warum dann diese Vermutungen? Ja, ich weiß, ich kenne ihn, er ist furchtbar ;-)
Aber zumindest die Javascriptimplementation ist recht sauber und auch ganz gut lesbar.

Noch eine Frage: Was soll ein Heap bei der Implementierung von switch bringen?

Ist in diesem Fall zum Sortieren ganz gut geeignet. Aber was für ein Baum das genau ist, kann ich ohne Rücksprache mit dem Code nicht sagen und den habe ich wahrscheinlich nicht hier,  da ich mir hinterm Modem sitzend nicht jeden neuen Mozilla sauge ;-)

so short

Christoph Zurnieden

PS:
Math.floor(Math.random() * 10) gibt keine ausreichende Menge an Zufallswerten.
CZ

[Daniel Thoma]

Das verstehe ich nicht. Was soll das bringen?

Wenn die Vergleiche zu schnell sind (z.B. vergleiche von Integers) sind alle drei Varianten so schnell, dass keine unterschiede Messbar sind. Das war zumindest mein erster Eindruck.
Wie Du allerdings unten richtig anmerkst, habe ich natürlich viel zu wenig Zufallszahlen erzeugt. Ich habe das auch bei meinem Test geändert aber irgendwie eine falsche Version hier rein kopiert.
Meine Ergebniss beziehen sich also auf Werte, wie sie mit werte.push("'w" + Math.random() + "'"); erzeugt werden.
Das vorangestellte w dürfte unnötig sein, aber ich wollte sicherstellen, dass ein Stringvergleich durchgeführt wird, damit die Ergebnisse deutlicher ausfallen.

Auch einen Baum (wenn auch nicht jeden) kann man in konstanter Zeit durchsuchen.

Wie kann man überhaupt in konstanter Zeit suchen?
Bei Hashtabellen wird ja nicht gesucht, sondern das Ziel berechnet.

Aber ein Frage: wenn Du den Mozilla benutzt ist die Wahrscheinlichkeit recht hoch, das Du in den Code schauen kannst.

Ich hab mir den Mozillacode noch nie angesehen. Daher wäre vermutlich doch etwas mehr Zeit notwendig, um mich darin zurecht zu finden.

Ist in diesem Fall zum Sortieren ganz gut geeignet.

Zum sortieren ja, bei einem Interpreter wäre natürlich auch entscheident, wie schnell da sortiert wird.

Grüße

Daniel

[Christoph Zurnieden]

Hi,

Das verstehe ich nicht. Was soll das bringen?
Wenn die Vergleiche zu schnell sind (z.B. vergleiche von Integers) sind alle drei Varianten so schnell, dass keine unterschiede Messbar sind. Das war zumindest mein erster Eindruck.

Nunja, Javascript Profiling ist zwar nur sehr begrenzt möglich, aber "kompliziertere Vergleiche" bringen es nicht wirklich ;-)

Wie Du allerdings unten richtig anmerkst, habe ich natürlich viel zu wenig Zufallszahlen erzeugt. Ich habe das auch bei meinem Test geändert aber irgendwie eine falsche Version hier rein kopiert.

Ja, der C&P-Fehlerteufel hat schon so manches Mal zugeschlagen, da ist niemand gegen gefeit ;-)

Meine Ergebniss beziehen sich also auf Werte, wie sie mit werte.push("'w" + Math.random() + "'"); erzeugt werden.
Das vorangestellte w dürfte unnötig sein, aber ich wollte sicherstellen, dass ein Stringvergleich durchgeführt wird, damit die Ergebnisse deutlicher ausfallen.

Und warum hast Du dann nicht für beide Integer genommen? Immerhin wäre das die portabelste und damit auch vergleichbarste Lösung gewesen.

Aufsteigende Vergleichswerte mit absteigender Abfrage wäre da ideal gewesen.

Auch einen Baum (wenn auch nicht jeden) kann man in konstanter Zeit durchsuchen.
Wie kann man überhaupt in konstanter Zeit suchen?
Bei Hashtabellen wird ja nicht gesucht, sondern das Ziel berechnet.

Noch nicht einmal das, sondern es wird nur die Wahrscheinlichkeit erhöht, das die zufällig angewählte Adresse die richtige ist. Ein wahrhaft injektives Mapping, einen perfekten Hash gibt es eher selten.

Aber ein Frage: wenn Du den Mozilla benutzt ist die Wahrscheinlichkeit recht hoch, das Du in den Code schauen kannst.
Ich hab mir den Mozillacode noch nie angesehen. Daher wäre vermutlich doch etwas mehr Zeit notwendig, um mich darin zurecht zu finden.

Wen Du nicht gerade viel Zeit hast, und ich meine wirklich viel Zeit, dann laß es lieber. Ich hatte mich mal etwas intensiver mit Mozillas Javascript beschäftigt und vor allem den mozillaeigenen Teilen davon. Hin und wieder hatte einmal die Dokumentation nicht mit dem Verhalten übereingestimmt und ich mußt mich durch den Code wühlen. Es war keine Freude.
Und der Javascript Teil scheint mir noch einer der Besseren zu sein.

Ist in diesem Fall zum Sortieren ganz gut geeignet.
Zum sortieren ja, bei einem Interpreter wäre natürlich auch entscheident, wie schnell da sortiert wird.

Puh ... wenn ich Dir jetzt ein "Groß Oh" an den Kopf schmeiße kannst Du da nichts mit anfangen, oder?

Aber ich hab's ja auch angefangen, dann muß ich da wohl jetzt auch durch ;-)

Bevor jedoch die große Forumsschere zuschlägt weil dieses Posting zu lang wird, erstmal bis hierhin, der Rest dann morgen (aber wahrscheinlich erst abends)

so short

Christoph Zurnieden

[Daniel Thoma]

Hallo Christoph!

Puh ... wenn ich Dir jetzt ein "Groß Oh" an den Kopf schmeiße kannst Du da nichts mit anfangen, oder?

Doch kann ich schon. Das war auch weniger eine Frage, (ich weiß, dass man mit einem Heap in O(n log n) sortieren kann) sondern eher laut gedacht. Beim kompilieren würde das sortieren ja nicht zur Laufzeit passieren, weswegen es relativ egal ist, wie man da sortiert. Beim Interpretieren ist es aber wichtig. Daher ist mir nun auch klar, wieso Du da Heaps erwähnt hast.

Grüße

Daniel

[Christoph Zurnieden]

Hi,

Puh ... wenn ich Dir jetzt ein "Groß Oh" an den Kopf schmeiße kannst Du da nichts mit anfangen, oder?
Doch kann ich schon.

Tja, das ist immer recht kompliziert, zu erfahren wieviel der Gesprächspartner an Vorwissen hat, ohne das sich irgendjemand auf den Schlips getreten fühlt.
(Und für eine Internetrecherche, ja, selbst nur eine Forumsarchivsuche ist man doch meist zu faul, ich gebe es ja zu ;-)

Das war auch weniger eine Frage, (ich weiß, dass man mit einem Heap in O(n log n) sortieren kann) sondern eher laut gedacht. Beim kompilieren würde das sortieren ja nicht zur Laufzeit passieren, weswegen es relativ egal ist, wie man da sortiert. Beim Interpretieren ist es aber wichtig. Daher ist mir nun auch klar, wieso Du da Heaps erwähnt hast.

Na, siehst Du, und da behaupten die Leute im Forum könnte man nix lernen ;-)

Aber: danke, das Du mir die Mühen abgenommen hast, in dem doch arg begrenztem Raum eines Forumpostings Komplexitätstheorie leicht verständlich darlegen zu müssen.
Das hatte mir heute den ganzen Tag schon Sorgen bereitet ;-)

Aber da hier in letzter Zeit Probleme mit Mark-Up deutlich hinter Programmierproblemen hinterherhecheln, wäre es vielleicht mal an der Zeit, einen kurzen(!) Artikel über "Sinn und Unsinn von Mikro-Optimierung" zu verfassen?

Es gibt zwar berufenere Kompetenzen hier im Forum als mich, aber irgendeiner muß ja erst mal etwas anbieten, damit dann nachher auch etwas da ist zum Verreißen  ;-)

so short

Christoph Zurnieden

[Daniel Thoma]

Hallo Christoph,

Aber da hier in letzter Zeit Probleme mit Mark-Up deutlich hinter Programmierproblemen hinterherhecheln, wäre es vielleicht mal an der Zeit, einen kurzen(!) Artikel über "Sinn und Unsinn von Mikro-Optimierung" zu verfassen?

Was soll da drin stehen? Dass man das idR bleiben lassen soll und dass Programme idR nicht langsam sind, weil das eine Konstrukt ein Bisschen langsamer ist als das andere, sondern weil man den falschen Algorithmus oder die falsche Datenstruktur gewählt hat und dass man deswegen lieber sauber und verständlich programmiert anstatt zu "optimieren"?
Bislang gibt es allerdings doch recht wenig solcher Fragen meine ich. Das kann aber auch daran liegen, dass ich das Thema PHP weitgehend ignoriere.

Grüße

Daniel

[Christoph Zurnieden]

Hi,

Aber da hier in letzter Zeit Probleme mit Mark-Up deutlich hinter Programmierproblemen hinterherhecheln, wäre es vielleicht mal an der Zeit, einen kurzen(!) Artikel über "Sinn und Unsinn von Mikro-Optimierung" zu verfassen?
Was soll da drin stehen? Dass man das idR bleiben lassen soll und dass Programme idR nicht langsam sind, weil das eine Konstrukt ein Bisschen langsamer ist als das andere, sondern weil man den falschen Algorithmus oder die falsche Datenstruktur gewählt hat und dass man deswegen lieber sauber und verständlich programmiert anstatt zu "optimieren"?

Ja.
Nur in etwas mehr und auch kürzeren Sätzen ;-)

Aber hast wahrscheinlich Recht: würde nichts nützen *sigh*

Bislang gibt es allerdings doch recht wenig solcher Fragen meine ich.

Direkt gibt es die eher selten, das stimmt. Aber von der Krankheit Micro-Optimierung ist ja nicht nur die Sucht nach extra Frames betroffen. Man könnte es manchmal auch treffender damit beschreiben, das jemand den Wald vor lauter Bäumen nicht sieht und deshalb verzweifelt an den Symptomen herumdoktort. Auch eine Form der Micro-Optimierung. Das gibt es sogar bei Mark-Up und nennt sich dort dann: "pixelgenaues Design".

Das kann aber auch daran liegen, dass ich das Thema PHP weitgehend ignoriere.

Das versuche ich auch, aber es hilft nicht, davon geht's leider nicht weg >;->

so short

Christoph Zurnieden

[MudGuard]

Hi,

Viele Fallunterscheidungen durch if-Anweisungen zu untescheiden oder ein Switch-Case Block zu programmieren?

In den Fällen, in denen sowohl switch als auch if ... else if ... else ...; möglich ist (also wenn ein Ausdruck mit verschiedenen Werten verglichen wird), gibt es vor allem einen Unterschied:

bei switch wird der Ausdruck genau einmal ausgewertet.
Bei if ... wird der Ausdruck mindestens einmal ausgewertet (wie oft genau hängt dann davon ab, welcher der Zweige zutrifft).

cu,
Andreas