Klammersetzung (ich seh grad den Wald vor lauter Bäumen nicht)

[Hensen]

Hi,

was ist an dieser Codezeile denn falsch?

  
if (  ( ($row[1] IS NOT NULL ) && (mysql_num_rows($result) %2 == 1) ) || ($row[0]==2)  ) {  
  

Danke, Hensen

[Hugo]

  
if(($row[1] IS NOT NULL && mysql_num_rows($result) % 2 == 1) || $row[0] == 2)

sollte passen ;)

[Hensen]

if(($row[1] IS NOT NULL && mysql_num_rows($result) % 2 == 1) || $row[0] == 2)

>   
> sollte passen ;)  
  
Erstmal dankeschön.  
  
Leider passt es aber nicht :-(  
  
Grüße, Hensen

[Hugo]

Es is richtig geklammert, zmd in einer Variante ;)
Kommt denn ne Fehlermeldung? Oder geht er nicht in den IF Zweig? Etwas mehr Code, oder du erklärst mal eben was bezweckst.

Zudem würde ich das mysql_num_rows($result) in einer Var speichern.

[Bademeister]

Hi Hensen.

was ist an dieser Codezeile denn falsch?

Das kommt darauf an, was fuer eine Sprache es sein soll ;-)

Viele Gruesse,
der Bademeister

[Hensen]

Hi Hensen.

was ist an dieser Codezeile denn falsch?

Das kommt darauf an, was fuer eine Sprache es sein soll ;-)

Viele Gruesse,
der Bademeister

Deutsch, warum?

[Bademeister]

Deutsch, warum?

:-)

Ich hatte eher an die moeglichen Antworten PHP oder SQL gedacht. Na ja, Der Martin hat ja nun schon geholfen.

Viele Gruesse,
der Bademeister

[Peter Pan]

Hi!

Deutsch, warum?

Ich hatte eher an die moeglichen Antworten PHP oder SQL gedacht.

Sieht eher aus wie PHPSQL - also ohne 'oder' - oder, genauer gesagt: wie PHPSQLPHP...

off:PP

[Peter Pan]

Hi!

was ist an dieser Codezeile denn falsch?

Das kommt darauf an, was fuer eine Sprache es sein soll ;-)

Deutsch, warum?

Und warum postest Du es dann in der Rubrik PHP?

Mal im Ernst:

Dein Code

  

> > > if (  ( ($row[1] IS NOT NULL ) && (mysql_num_rows($result) %2 == 1) ) || ($row[0]==2)  ) {  
  

sollte Dir vom PHP-Interpreter mit einer Fehlermeldung quittiert werden - warum verschweigst Du diese?
"IS NOT NULL"  sieht nicht sehr PHPish aus -> die Funktion is_null existiert und ebenso der logische Operator ! für "Nicht".

In nicht ganz angestaubten PHP-Versionen ist auch die Anwendung der logischen Operatoren auf den Wert Null zulässig.

Also so etwas z.B:

  
!is_null($row[1]) // oder:  
$row[1]!== Null  

off:PP

[Garsten]

$row[1]!== Null

~~~php
  
$row[1]!= Null bitte  

[Peter Pan]

Hi!

$row[1]!== Null

> ~~~php
  

> $row[1]!= Null bitte  
> 

Magst Du das begründen wollen?

off:PP

[Hugo]

^^ naja wenn er es schon unter PHP postet ;)

[Der Martin]

Hallo,

if ( ( ($row[1] IS NOT NULL ) && (mysql_num_rows($result) %2 == 1) ) || ($row[0]==2) )

seit wann gibt es denn in PHP einen "IS"-Operator? Den hat dir wohl jemand untergeschoben, der dich veräppeln wollte.

Ciao,
 Martin

[Don P]

Hallo,

Hallo,

if ( ( ($row[1] IS NOT NULL ) && (mysql_num_rows($result) %2 == 1) ) || ($row[0]==2) )

seit wann gibt es denn in PHP einen "IS"-Operator? Den hat dir wohl jemand untergeschoben, der dich veräppeln wollte.

Wenn's gerade um Operatoren geht, für sowas:

(mysql_num_rows($result) %2 == 1)

d.h um auf gerade/ungerade Zahlen zu testen, leistet der &-Operator gute und vermutlich viel schnellere Dienste:

(mysql_num_rows($result) & 1)

Das ist mein Ernst, obwohl ich PHP eigentlich gar nicht kann. Musste den &-Operator erst nachschlagen...

Gruß, Don P

[Sven Rautenberg]

Moin!

Wenn's gerade um Operatoren geht, für sowas:

(mysql_num_rows($result) %2 == 1)

d.h um auf gerade/ungerade Zahlen zu testen, leistet der &-Operator gute und vermutlich viel schnellere Dienste:

(mysql_num_rows($result) & 1)

Das ist mein Ernst, obwohl ich PHP eigentlich gar nicht kann. Musste den &-Operator erst nachschlagen...

Deine Lösung mag vielleicht etwas schneller sein, aber definitiv ist sie obskurer, denn sie verbirgt ziemlich effektiv, was sie eigentlich bezwecken soll. Code wird in der Regel _einmal_ geschrieben. Aber danach von vielen Programmierern _sehr häufig_ wieder gelesen. Dieser Lesevorgang sollte so wenig Verwirrung hinterlassen, wie möglich.

Deshalb sollte Codeklarheit bei allen Überlegungen immer oberstes Gebot sein. Vor allem, wenn man PHP programmiert. Denn diese Sprache ist sowieso so langsam im Vergleich zu z.B. C, dass man sich diese blöden Mikro-Optimierungen wirklich schenken kann. Allein durch einen Wechsel der Sprache würde man einige Größenordnungen an Geschwindigkeit gewinnen. Aber darum geht es in der Regel gar nicht.

PHP ist deshalb toll, weil man damit in deutlich kürzerer Zeit zu Ergebnissen kommt, als mit anderen Sprachen. Die Performance mag an diesem Punkt vielleicht noch mies sein, aber immerhin hat man mindestens schon einen Prototypen, mit dem man experimentieren kann.

Facebook basiert komplett auf PHP. Deren aktueller Performance-Kniff ist, dass sie den PHP-Code in einen C++-Code umwandeln, der dann kompiliert wird, noch einen eigenen Webserver dazu bekommt, und als einzelnes ausführbares Programm abläuft - etwa 50% schneller, als das PHP-Original mit allen möglichen Optimierungen wie dem Einsatz von APC... (das haben die Jungs übrigens als Open Source veröffentlicht, nennt sich HipHop - und dürfte bei 90% aller normalen PHP-Sites irrelevant sein, weil der Use-Case von Facebook dort nicht vorliegt).

- Sven Rautenberg

[Don P]

Hallo Sven,

Deine Lösung mag vielleicht etwas schneller sein, aber definitiv ist sie obskurer, denn sie verbirgt ziemlich effektiv, was sie eigentlich bezwecken soll. Code wird in der Regel _einmal_ geschrieben. Aber danach von vielen Programmierern _sehr häufig_ wieder gelesen. Dieser Lesevorgang sollte so wenig Verwirrung hinterlassen, wie möglich.

Ok, aber Kommentare gibt's in PHP sicher auch. Ein kleiner Kommentar am Ende der Zeile könnte den Sinn erhellen. Kleinvieh macht bekanntlich auch Mist...

PHP ist deshalb toll, weil man damit in deutlich kürzerer Zeit zu Ergebnissen kommt, als mit anderen Sprachen. Die Performance mag an diesem Punkt vielleicht noch mies sein, aber immerhin hat man mindestens schon einen Prototypen, mit dem man experimentieren kann.

PHP ist also eine lahme Krücke? Gut, dass ich mich bis jetzt nicht näher damit befasset habe. Wäre Perl denn schneller?

Facebook basiert komplett auf PHP. Deren aktueller Performance-Kniff ist, dass sie den PHP-Code in einen C++-Code umwandeln, der dann kompiliert wird [...]

Weia, hätte man da nicht lieber gleich in C++ programmiert?

Gruß, Don P

[dedlfix]

Hi!

Ok, aber Kommentare gibt's in PHP sicher auch. Ein kleiner Kommentar am Ende der Zeile könnte den Sinn erhellen. Kleinvieh macht bekanntlich auch Mist...

Ja, aber was bringt es? Wenn die Änderung im Grundrauschen untergeht, gibt es garantiert keine Vorteile für den praktischen Betrieb. Die meiste Zeit wird für andere Dinge benötigt. Die Microoptimierung ändert nichts daran, dass ein Script jedes Mal neu übersetzt wird, dass danach immer noch Bytecode interpretiert werden muss, dass der Netzwerkverkehr Zeit benötigt. Du bekommst durch solches Kleinvieh in der Regel nicht genügend Einsparung, dass deswegen signifikant mehr Requests bedient werden können.

PHP ist also eine lahme Krücke? Gut, dass ich mich bis jetzt nicht näher damit befasset habe. Wäre Perl denn schneller?

Jede (quasi-)interpretierte Sprache ist langsam, wenn man sie mit kompilierten Anwendungen vergleicht. Da unterscheiden sich PHP, Perl, Python und so weiter nicht prinzipiell voneinander.

Wie gesagt, es zählt meist nicht, wie schnell es ausgeführt wird - das bekommt man auch mit Rechenpower gelöst - sondern wie schnell es entwickelt und gewartet werden kann. Programmierer kosten üblicherweise mehr als Hardware.

Facebook basiert komplett auf PHP. Deren aktueller Performance-Kniff ist, dass sie den PHP-Code in einen C++-Code umwandeln, der dann kompiliert wird [...]
Weia, hätte man da nicht lieber gleich in C++ programmiert?

Hätte, wäre, wenn. Oft fängt man ohne große Planung einfach an und muss dann später erkennen, dass es so nicht weitergeht oder man zumindest besser anfangen hätte können. Doch gerade bei laufenden Projekten kann man nicht einfach mal eben so komplett alles neu machen, zumal wenn die Konkurrenzsituation es nicht zulässt, dass die aktuelle Version mal ein Jahr lang (oder wie lange man für den Rewrite benötigt) keine neuen Features bekommt und viele Plugins hinterher nicht mehr laufen.

Lo!

[Der Martin]

Hallo,

(mysql_num_rows($result) %2 == 1)

vs.

(mysql_num_rows($result) & 1)

Deine Lösung mag vielleicht etwas schneller sein, ...

möglich, aber groß dürfte der Unterschied nicht sein.

aber definitiv ist sie obskurer, denn sie verbirgt ziemlich effektiv, was sie eigentlich bezwecken soll.

Aber ganz im Gegenteil! Die Funktion soll offensichtlich ungerade von geraden Zahlen unterscheiden. Wodurch zeichnen sich ungerade Zahlen aus? Doch dadurch, dass in ihrer Binärdarstellung das Bit0 gesetzt ist. Also ist es doch naheliegend und intuitiv, auch genau diese Bedingung direkt zu testen, anstatt eine Modulo-Operation zu formulieren, bei der man erst nach kurzem Grübeln über die Teilbarkeit durch 2 darauf kommt: "Ach ja, so könnte man's auch machen." Das ist ziemlich um die Ecke gedacht, finde ich.

Code wird in der Regel _einmal_ geschrieben. Aber danach von vielen Programmierern _sehr häufig_ wieder gelesen. Dieser Lesevorgang sollte so wenig Verwirrung hinterlassen, wie möglich.

Das spräche bei diesem Beispiel für die Verwendung der Bitmaskierung.

Deshalb sollte Codeklarheit bei allen Überlegungen immer oberstes Gebot sein.

ACK.

Vor allem, wenn man PHP programmiert.

Oh, ich finde, das sollte von der konkreten Programmiersprache unanhängig sein.

PHP ist deshalb toll, weil man damit in deutlich kürzerer Zeit zu Ergebnissen kommt, als mit anderen Sprachen. Die Performance mag an diesem Punkt vielleicht noch mies sein, aber immerhin hat man mindestens schon einen Prototypen, mit dem man experimentieren kann.

Und dabei bleibt's dann oft für die Ewigkeit. Wir wissen doch alle: Nichts ist so dauerhaft wie ein Provisorium, wenn's "funzt". ;-)

Ciao,
 Martin

[Don P]

Hallo,

(mysql_num_rows($result) %2 == 1)

vs.

(mysql_num_rows($result) & 1)

Deine Lösung mag vielleicht etwas schneller sein, ...

möglich, aber groß dürfte der Unterschied nicht sein.

Weiß nicht genau, in welchen Größenordnungen man da rechnen muss, aber angenommen, der Performancegewinn betrage nur 0,1 ms pro Berechnung, dann ergibt das beim Iterieren über 10'000 Datensätze bereits 1 Sekunde, und die "spürt" man durchaus. Ok, im konkreten Fall wird ja nicht iteriert, aber oft genug ist das der Fall, wenn man z.B. jede zweite Tabellenzeile einfärben will oder sowas.

aber definitiv ist sie obskurer, denn sie verbirgt ziemlich effektiv, was sie eigentlich bezwecken soll.

Aber ganz im Gegenteil! [...] ist es doch naheliegend und intuitiv, auch genau diese Bedingung direkt zu testen, anstatt eine Modulo-Operation zu formulieren, bei der man erst nach kurzem Grübeln über die Teilbarkeit durch 2 darauf kommt: "Ach ja, so könnte man's auch machen." Das ist ziemlich um die Ecke gedacht, finde ich.

Genau! Danke für die Unterstützung.

Vor allem, wenn man PHP programmiert.

Oh, ich finde, das sollte von der konkreten Programmiersprache unanhängig sein.

So ist es.

Btw, erst kurz nachdem ich meinen Bitmaskierungs-Vorschlag gepostet hatte, Martin, habe ich in deiner Signatur gelesen, dass man nicht immer alles sagen soll, was man weiß. Hätte ich es früher gelesen, wäre mein Beitrag wohl nicht erschienen ;)

Gruß, Don P

[dedlfix]

Hi!

Deine Lösung mag vielleicht etwas schneller sein, ...
möglich, aber groß dürfte der Unterschied nicht sein.
Weiß nicht genau, in welchen Größenordnungen man da rechnen muss, aber angenommen, der Performancegewinn betrage nur 0,1 ms pro Berechnung, dann ergibt das beim Iterieren über 10'000 Datensätze bereits 1 Sekunde, und die "spürt" man durchaus.

Ja, aber dann hast du auch 10.000 Datensätze, die du weiterverarbeiten musst. Das verbraucht in der Regel deutlich mehr Zeit, so dass die Sekunde nicht mehr ins Gewicht fällt. Bei dem gegebenen Beispiel wirst du aber schätzungsweise erst bei 1 Million Iterationen in den Sekundenbereich kommen, und 1 Million Datensätze ...

Ok, im konkreten Fall wird ja nicht iteriert, aber oft genug ist das der Fall, wenn man z.B. jede zweite Tabellenzeile einfärben will oder sowas.

Ja, aber selten mit mehr als 100 Datensätzen gleichzeitig (pro Seite).

aber definitiv ist sie obskurer, denn sie verbirgt ziemlich effektiv, was sie eigentlich bezwecken soll.
Aber ganz im Gegenteil! [...] ist es doch naheliegend und intuitiv, auch genau diese Bedingung direkt zu testen, anstatt eine Modulo-Operation zu formulieren, [...]

Ich meine, beide Fälle wirken auf den unerfahrenen Leser nicht sofort einleuchtend. Im ersten Fall, muss man die Modulo-Operation kennen, im zweiten muss man sich auf Bit-Ebene begeben, obwohl man sonst eher selten damit in Berührung kommt. Vielleicht ist am besten erkennbar, wenn man eine boolsche Variable nimmt, die man immer hin und her schaltet (Performance außer Acht lassen, spielt sowieso keine gravierende Geige).

Lo!

[Steel]

Hi!

Ich meine, beide Fälle wirken auf den unerfahrenen Leser nicht sofort einleuchtend. Im ersten Fall, muss man die Modulo-Operation kennen, im zweiten muss man sich auf Bit-Ebene begeben, obwohl man sonst eher selten damit in Berührung kommt. Vielleicht ist am besten erkennbar, wenn man eine boolsche Variable nimmt, die man immer hin und her schaltet (Performance außer Acht lassen, spielt sowieso keine gravierende Geige).

Korrekt!

Ich erlebe das dauernd. Oft genug muessen die Kollegen hier an alten Code ran. (in diesem Fall normalerweise 'nur' VBA) Oft genug muss ich dann nochmal nachbessern, weil schlichtweg Mist ist, was rauskommt. Der Code ist Scheisse und die Leute koennen nicht programmieren. Wie sollte es also anders sein? Keiner von denen weiss, was Modulo ist. Und jetzt sollen sie mit Bits spielen?

Waehrend meiner Ausbildung zum Informatiker hatte ich einen !!-> Dozenten <-!! fuer Javascript, der allen ernstes meinte minuten%60 wuerde die Anzahl der Sekunden ausrechnen. Auch Prozentrechnung wird immer gern erwaehnt. Fuer mich hat er damals damit jeden Respekt verloren. Manchmal macht man Ausbildungen nur um irgendeinen Wisch zu bekommen, auf dem steht dass man es kann. Was son Papier eigentich wert ist, mag jeder fuer sich selbst entscheiden.

Wir reden ja hier nicht ausschliesslich ueber gestandene Programmierer. Der Code soll gewoehnlich verstaendlich sein fuer den Noob, der eben sein Forum oder seine Stundenplantabelle anpassen will und vorher noch nie was mit php gemacht hat. Woher kommen denn sonst all die Fragen im Forum? Und gerade diese spezielle Frage beweist das doch, oder nicht?

Natuerlich ist es nicht verkehrt auch auf andere Loesungswege einzugehen. Der ein oder andere Leser ist halt kein blutiger Anfaenger oder entwickelt sich durch solche Antworten vom Anfaenger zum versierten Programmierer, weil er es eben versteht. (von der hier diskutierten Sinnhaftigkeit einer solchen Loesung im vorgegbenen Umfeld mal abgesehen) Es entstehen hier ja oft genug Threads in denen Dinge diskutiert werden, die weit abgehoben vom ursprunglich gefragtem sind und dem Fragesteller sicher nicht weiterhelfen. Schlecht ist sowas ja nicht, solange der Fragesteller auch _fuer ihn_ brauchbare Hilfe bekommt.

[Der Martin]

Hi,

(mysql_num_rows($result) %2 == 1)
vs.
(mysql_num_rows($result) & 1)

möglich, aber groß dürfte der Unterschied nicht sein.
Weiß nicht genau, in welchen Größenordnungen man da rechnen muss, ...

das kommt sehr darauf an, ob wir von einer interpretierten Sprache wie PHP ausgehen, oder von einer compilierten wie etwa C.

In einer compilierten Sprache, bei der das relevante Resultat am Ende reiner Maschinencode ist, müsste man direkt die CPU-Operation betrachten. Eine Bitmaskierung macht so ziemlich jede CPU in einem einzigen Taktzyklus (zusätzliche Zyklen zum Lesen der Instruktion mal nicht berücksichtigt). Eine Modulo-Operation, also letztendlich eine Division, wird zwar auf modernen CPUs auch mit einer einzigen Instruktion codiert, braucht aber deutlich mehr Taktzyklen (Faustregel: mindestens so viele, wie die Operanden Bits haben). Wir haben hier also einen Vorteil von beispielsweise 1:32 für die Bit-Operation. Wenn man das Drumherum, den Rest der Schleife, noch berücksichtigt, reduziert sich das Verhältnis etwas, die Bit-Operation behält aber die Nase vorn.
Nur: MERKT man das nachher wirklich? Ob so eine Schleife mit werweißwieviel Durchläufen 24ms oder 26.2ms braucht, fällt wohl nicht wirklich ins Gewicht. Also kann man mit gutem Gewissen die Schreibweise verwenden, die einem besser gefällt - zumal gute Compiler teils Integer-Divisionen oder Multiplikationen mit einer Zweierpotenz als Konstante automatisch zu einem Bit-Shift optimieren.

Bei einer interpretierten Sprache wie PHP ist der Unterschied der reinen Berechnung aufgrund des Interpreter-Overheads *viel* geringer, und wird noch weniger relevant, wenn man den restlichen Code der Schleife mit betrachtet.
Auch hier ist also das Fazit: Die beiden Varianten sind in der Performance nicht merklich verschieden (vielleicht messbar).

aber angenommen, der Performancegewinn betrage nur 0,1 ms pro Berechnung

Das ist bei heutigen Maschinen vermutlich schon viel zu hoch gegriffen.

Btw, erst kurz nachdem ich meinen Bitmaskierungs-Vorschlag gepostet hatte, Martin, habe ich in deiner Signatur gelesen, dass man nicht immer alles sagen soll, was man weiß. Hätte ich es früher gelesen, wäre mein Beitrag wohl nicht erschienen ;)

Warum das denn? Manche Dinge *sollten* einfach gesagt werden.

So long,
 Martin