Rein rhetorische/informative Frage über Variablennamen in PHP

[Amateur_builder]

Hallo liebe Community,
Mir kam einfach mal die Frage in den Kopf, ob es Performance einbußen bei PHP gäbe, je länger der Name einer Variable oder einer Klasse, die gerade benutzt wird. Theoretisch müssen ja auch die Namen der Variablen im Arbeitsspeicher des Server gespeichert werden. Also würde es Sinn machen, die Namen kurz zu halten? Oder ist der benötigte Speicher dafür so unsignifikant klein, dass man lieber Aussagekräftige Namen den kurzen bevorzugen sollte? (Sonst würde man kurze Namen wählen und mit einem Kommentar beschreiben wozu die Variable gut ist.)

MfG Amateur_builder

 

[Dissolution]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Der Speicher ist so insignifikant größer, dass es weitaus besser ist aussagekräftige Variablennamen zu wählen (gilt natürlich ebenso für Methoden, Klassen etc.), als anzufangen alles "a", "aa", "ab" etc. zu nennen, es sei denn es macht Sinn.

Die Performance die du, eventuell, gewinnst, steht in keinem Verhältnis zu der "ProgrammierER"-Performance die du verlierst.
Sprich die Zeit die du nach einigen Monaten brauchst um dich wieder einzuarbeiten, oder auch jemand anders, ist viel kostbarer als die paar Microsekunden die du eventuell, wenn du eine wirklich große Applikation schreibst, einsparen könntest.

http://programmers.stackexchange.co...able-names-affect-the-performance-of-websites

Aber ja, rein hypothetisch gesprochen hast du natürlich Recht.

(Kommt übrigens auch auf die Sprache an. Wenn's erst kompiliert werden muss, ist es wieder "völlig" (eher) egal was für Variablen-Namen du verwendest, da die sowieso in irgendeine Form von "Byte-Code" übersetzt werden und der Compiler da seine eigene "Logik" hat, aber das nur am Rande.)

 

[rodemund]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Bin kein PHP-Profi, aber ich nehme an, dass im Arbeitsspeicher der Platz für einen Variablennamen eh reserviert ist.

Außerdem bekommt der ausgeführte Code den Variablennamen wahrscheinlich eh nie zu Gesicht, weil der Variablennamen nur einen Pointer definiert und sonst nichts.

Ich habe mich durchaus ein wenig um PHP gekümmert, und das war noch nie irgendwo Thema - könnte ein Hinweis sein, dass es bedeutungslos ist.

PHP ist auch eine Interpretersprache. Das bedeutet, wenn's zeitkritisch wird, ist es eh die verkehrte Haustür.

Wenn man zum Schluss - falls das Ganze überhaupt eine messbare, geschweige denn tragende Rolle spielt - das Verhältnis bedenkt von verschwendeter Entwicklungszeit durch kurze, kryptische Namen zu evtl. gesparter Laufzeit, dann wird's endgültig irrelevant.

Bei PHP kann man IMHO die meiste Laufzeit sparen durch schlaue Programmierung.

 

[Dissolution]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Bei PHP kann man IMHO die meiste Laufzeit sparen durch schlaue Programmierung.

Das gilt für praktisch jede "Highlevel"-Sprache

 

[Wellenbrecher1963]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

und die Zeiten, bei denen man Kaffe kochen konnte, bis ein Server eine Anfrage bearbeitet hatte, sind doch Gott sei Dank vorbei. Die Server haben doch heute bei den Hostern in der Standardausführung schon 2 oder mehr Kerne. Bei einigen Systemen kann man sogar die Kerne bei Rechenaufgaben aufteilen. Also z.B. ein Kern für die Seitendarstellung, ein Kern für die mySQL Geschichte usw.

Ein Kooperationspartner nutzt einen "mitwachsenden" Server. Er kann nahezu Minütlich Änderungen an der Konfiguration machen und wie beschrieben, die Kerne zuteilen. Das Ding ist der Renner und der Hammer. Und wenn man erfährt, was man nur dafür bezahlt, fällt man ab vom Glauben. Einziger Nachteil - wenn man irgend eine Einstellung zurück setzen muss - also Downgrate - muss die Platte neu formatiert werden. Beim Update ist das anders. Wird nur wieder was eingeklinkt und fertig. Ausklinken geht nicht.

Aber trotzdem ein Hammer Teil.

So long

 

[Dissolution]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Ein Kooperationspartner nutzt einen "mitwachsenden" Server. Er kann nahezu Minütlich Änderungen an der Konfiguration machen und wie beschrieben, die Kerne zuteilen. Das Ding ist der Renner und der Hammer. Und wenn man erfährt, was man nur dafür bezahlt, fällt man ab vom Glauben. Einziger Nachteil - wenn man irgend eine Einstellung zurück setzen muss - also Downgrate - muss die Platte neu formatiert werden. Beim Update ist das anders. Wird nur wieder was eingeklinkt und fertig. Ausklinken geht nicht.

Horizontal skalierend?

 

[DoctorG]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Höre auf Dissolutions Worte!
Ich lebe als Berater - unter anderem für Code-Quality - von Firmen, denen solche "Ersparnisse" passiert sind und wo keiner mehr durchblickt (... ich biete Strategien, um aus der Situation rauszukommen). Denn: das geht tückisch schnell! Wenn der Code plötzlich wichtig wird, ist der Ärger groß.
Eine normale Fehlerquote eines Programmierer - das grenzt an ein Naturgesetz - ist etwa 4-10 Fehler auf 100 Zeilen Quelltext. Erst mit weiterer Methodik wie Unit-Tests, Code-Reviews, automatischen Code-Audits schaffen Menschen es überhaupt, die Quote nennenswert darunter zu bringen. Und diese Fehlerquote hat man bereits ohne dass man sich die Sicht durch ungeschickte Benennungen von Variablen, Funktionen etc. weiter erschwert. Also kurz gesagt: wenn Du Deine Reklamationsquote (oder auch im Eigenbetrieb Quote der Nachbesserungen) nach oben treiben willst, dann ist Sparen einiger Buchstaben ein guter Weg für weitere Denkfallen, die das nachweislich wirksam auslösen.
Aus technischer Sicht würde ich aber ohnehin eine Optimierung des jeweiligen Interpreters/Compilers erwarten, wenn der menschengeschriebene Code auf die maschinenebene abgebildet wird. Ich schreib das jetzt mal so allgemein, weil ich nicht weiß wie PHP unter der Haube aussieht. Stand der Technik ist so was aber eigentlich seit 20 Jahren.

Und wenn Du es ganz genau wissen willst, dann mess das doch mal nach:
Schreib Dir mal kurz zwei Programme, die einfach dieselben paar hundert Zählschleifen von 0 bis zu Millionen oder Milliarden aufweist (je nachdem wobei Du bei Deinem Testsystem das Ende noch erlebst; wichtig ist nur, dass Du einen Zahlenbereich findest, in dem Du die Ausführungsdauer als solche überhaupt wahrnimmst). Einmal nimmst Du elend lange Dateinamen und einmal die typischen "i"s für die Zählvariablen.
Dann wirst Du sehen, ob es einem Unterschied macht und wenn ja, wie groß er ist. Ich rechne hier mit keinem aber Versuch macht ja Kluch.

 

[Duddle]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Auch wenn das einen Hauch Off-Topic ist, will ich die Gelegenheit mal schamlos ausnutzen:

Erst mit weiterer Methodik wie Unit-Tests, Code-Reviews, automatischen Code-Audits schaffen Menschen es überhaupt, die Quote nennenswert darunter zu bringen.

In welcher Priorität sollten die üblichen Maßnahmen implementiert werden? Welche Technik hat den größten Nutzen pro investierter Zeiteinheit (mglw. noch "abhängig vom Alter/Fortschritt des Projekts")?


Duddle

 

[rodemund]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

... elend lange Dateinamen und einmal die typischen "i"s ...

<klugscheissmodus>
Wahrscheinlich meinst du "Variablennamen"?
</klugscheissmodus>

... sorry. Es war stärker als ich ;D

PS.: im Übrigen goldene Worte, dein Post. Danke dafür.

Grüße

 

[Dissolution]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Aus technischer Sicht würde ich aber ohnehin eine Optimierung des jeweiligen Interpreters/Compilers erwarten, wenn der menschengeschriebene Code auf die maschinenebene abgebildet wird. Ich schreib das jetzt mal so allgemein, weil ich nicht weiß wie PHP unter der Haube aussieht. Stand der Technik ist so was aber eigentlich seit 20 Jahren.

Würd ich so unterschreiben. Hab leider auch keine Ahnung wie PHP genau arbeitet. Es gibt Compiler dafür, aber die sind optional.

Anscheinend wird ein Interpreter drüber gejagt. Inwiefern der verbessert, keine Ahnung.

Aber das mit den Variablen ist ganz lustig, man verliert nämlich schon bei sehr kleinen Projekten recht schnell die Übersicht, wenn man derartige Konstrukte fabriziert:

Klasse A {
int a;
int b;

    methodenname(int c, double d) {
       a = c;
       b = (int)d;
   }
}

Klasse B {

boolean a;
long c;

    methodenname(boolean b, int d) {
      a = b;
      c = d;
   }
}

Das ist jetzt nur ein winziges Beispiel, aber durch die Einsparung an Buchstaben ist man, wenn mans wirklich drauf anlegt, sehr eingeschränkt und es wird absolut unübersichtlich was da überhaupt passiert.

(Das traurige an dem Beispiel ist auch, dass nicht mal "this" verwendet wurde. Ist zwar jetzt nur Pseudocode, hab ich aber so im echten Leben gesehen)

Je nach Sprache und Warnungen wächst die Arbeit bei der Fehlersuche so überexponentiell an

 

[DoctorG]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

@alterneuling: ja - rischtisch, Variablennamen. (4-10 Fehler auf 100 Zeilen, nicht nur beim Coden, und auch wenn man's weiß ...)

@duddle:
Nach meiner Erfahrung haben Unit-Tests den größten Hebel, solange es um Funktionalität geht (wenn es um Oberflächen/GUI geht, dann natürlich Usability-Tests mit Testpersonen).
Da ist der Stand der Technik heute, dass man eigentlich nicht wettbewerbsfähig ist, wenn man bei neuen Projekten nicht auf diesem Niveau anfängt. Ich kenne natürlich Firmen, bei denen das nicht der Fall oder die Uralt-Legacy-Umgebung kein gescheites Testing-Framework hat (PowerBuilder zum Beispiel ist da bis heute nicht richtig unterstützt). Und das merkt man dann eben alle fünf Klicks lang, dass das mit den Überraschungen so ist wie in den 90ern - heute aber eben nicht mehr akzeptiert. Wer sowas hat, nutzt es weiter, gut. Wenn allerdings jemand etwas auf dem Niveau neu verkaufen will, endet das Vertrauen nach einigen Tagen mit Testversionen schnell, wenn die Fehlerdichte so hoch ist. Wenn dann eben auch Berater als Gutachter/Unterstützer dabei sind, sinken da die Daumen wegen der uneinschätzbaren aber sich andeutendne Risiken schnell (Eisberg-Gleichnis: wenn das hier auch nur 10 Prozent von Ärger sind, den wir jetzt schon sehen ...)
Viele Firmen machen damit so gute Erfahrungen, dass sie in wichtigen Projekten festlegen, dass am Besten zuerst die Testfälle geschrieben werden und dann erst der Soll-Code dazu. Das ist dann das sog. Test-Driven Development (TDD).

Code-Audits - also automatische Bewertungen wie z.B. Einhaltung von Konventionen, max. Zeilenanzahl je Methode, defensives Exception-Handling (nicht alles gleich zur Wurzel durchreichen) - sollte man aktivieren, wenn eine Umgebung wie etwa Visual Studio gleich im Karton hat. Für andere Welten auch verfügbar, da muss man aber wieder mehr Zeit investieren (f. Java etwa: Findbugs oder PMD oder CheckStyle oder alle drei, aber mit welchen Regelsets ...). Und: man muss es managen. Die Regeln müssen für alle Entwickler gleich sein. Das erfordert Meetings, einen Verantwortlichen, Moderation etc. Ist etwas fortgeschrittener. Für Projekte bzw. eigentlich Organisationen, die z.B. höhere CMMI-Level zertifiziert bekommen möchten, aber ab einem bestimmten Grad Pflicht.
Code-Reviews: Für kritischere Codes, bei denen Fehler sehr teuer oder sogar strafrechtlich enden können, sind dann Code-Reviews entweder gut oder wiederum sowieso Pflicht. Hierbei führt der Entwickler in Meetings durch seinen Code, die fachlich kompetenten Teilnehmer haben ihn ebenfalls vorher gelesen/studiert. Und gemeinsam wird entschieden, ob das reif ist oder zuviele Denkfehler oder Wartungsfallen drin sind. Denn: auch wenn z.B. ein Code jetzt gut läuft, ist es ja auch übel, wenn man schon sieht, dass ein Kollege in der Wartung in x Jahrren etwas recht sicher missverstehen wird und z.B. eine Bremssteuerung danach zur Todesfalle mutieren könnte. Das Beispiel zeigt auch für welche Codes man sowas macht: Bankensoftware, an denen Unsummen hängen oder Steuerungssoftware, deren Fehlfunktionen Sicherheitsrisiken realisieren würden. Das macht man selten für die Steuerung eines M-P-3-Players.

 

[rodemund]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

@
... sprich ruhig weiter ... ist bei dir evtl. noch ein Studienplatz frei? ;D

 

[Amateur_builder]

AW: Rein rhetorische/informative Frage über Variablennamen in PHP

Danke für eure vielen Antworten Leute. Sind ja auch eineige interessante Erklärungen und Meinungen mit dabei, im Allgemeinen gehe ich aber auch davon aus, dass, falls der richtige Variablennamen im Arbeitsspeicher landet, nur unsignifikant größer ist pro Buchstabe. Oder falls, wie @alterneuling sagte, es würde nur ein Pointer gesetzt, klingt auch ganz einleuchtend. So ganz habe ich mich auch nie damit beschäftigt, wie PHP unter der Haube arbeitet