Hi,

ich wollte mal Fragen, ob es Erfahrungswerte gibt in wie fern sich viele
Kommentare auf die Laufzeit auswirken?

Bei kompilierten Sprachen werden diese vom Compiler ignoriert und
tauchen im späteren Programm nicht mehr auf, aber bei Skriptsprachen wie
PHP muss der Interpreter immer wieder aufs neue die komplette Datei
lesen und interpretieren.

Hintergrund des ganzen ist die API Dokumentation, welche ich verwende
und (sollte sich das nicht merklich negativ auswirken) die Erweiterung
dieser um Anwendungsbeispiele und ausführlichere Beschreibungen. Das
Ganze würde zwar die Verständlichkeit erhöhen, aber womöglich auch die
Laufzeit beeinflussen, was ich gerne im Vorfeld in Erfahrung bringen würde.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Hi,
>
> ich wollte mal Fragen, ob es Erfahrungswerte gibt in wie fern sich viele
> Kommentare auf die Laufzeit auswirken?
>
> Bei kompilierten Sprachen werden diese vom Compiler ignoriert und
> tauchen im späteren Programm nicht mehr auf, aber bei Skriptsprachen wie
> PHP muss der Interpreter immer wieder aufs neue die komplette Datei
> lesen und interpretieren.

Ja, aber auch der Interpreter ignoriert deine Kommentare. Solltest du
PHP3 verwenden, ist es tatsächlich beschleunigend sie zu entfernen.
Im normalen Gebrauch seit PHP4 ist die Wirkung aber gerade mal messbar
und vernachlässigbar gering.

Gruß,
Torsten

Christoph Herrmann schrieb:
> Hi,
>
> ich wollte mal Fragen, ob es Erfahrungswerte gibt in wie fern sich viel=
e
> Kommentare auf die Laufzeit auswirken?

Wirkt sich nicht aus.

> Bei kompilierten Sprachen werden diese vom Compiler ignoriert und
> tauchen im späteren Programm nicht mehr auf, aber bei Skriptsprachen =
wie
> PHP muss der Interpreter immer wieder aufs neue die komplette Datei
> lesen und interpretieren.
>
> Hintergrund des ganzen ist die API Dokumentation, welche ich verwende
> und (sollte sich das nicht merklich negativ auswirken) die Erweiterung =

> dieser um Anwendungsbeispiele und ausführlichere Beschreibungen. Das =

> Ganze würde zwar die Verständlichkeit erhöhen, aber womöglich a=
uch die
> Laufzeit beeinflussen, was ich gerne im Vorfeld in Erfahrung bringen wü=
rde.

Hier macht Inline Doku bzw. API Beschreibung bis zu 30% aus. Für den
Parser ist dies nicht relevant und im Bereich der Messungenauigkeit.

Was aber relvant ist sind Caches des OS welche evt. besser genutzt
werden koennen wenn die Dateien kleiner sind bzw. mehr Daten in den
Cache passen. Wenn du aber Xcache/APC und co. Verwendest sollte das
allerdings auch keine Rolle spielen weil ich mal hoffe das Bytecode
keine Kommentare hat.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Hallo Christoph Herrmann! Du schriebst:

> ich wollte mal Fragen, ob es Erfahrungswerte gibt in wie fern sich viele
> Kommentare auf die Laufzeit auswirken?

Die FAQ dieser Gruppe hat dazu nen Beitrag parat.

27.7. Schaden Kommentare der Performance?
http://www.php-faq.de/q/q-stil-kommentare.html

MfG, Ulf

Joerg Behrens schrieb:
> Hier macht Inline Doku bzw. API Beschreibung bis zu 30% aus. Für den
> Parser ist dies nicht relevant und im Bereich der Messungenauigkeit.

bei was macht es 30% aus? Bei deinem Quellcode oder bei der
Geschwindigkeit des Parsers allgemein?

> Was aber relvant ist sind Caches des OS welche evt. besser genutzt
> werden koennen wenn die Dateien kleiner sind bzw. mehr Daten in den
> Cache passen. Wenn du aber Xcache/APC und co. Verwendest sollte das
> allerdings auch keine Rolle spielen weil ich mal hoffe das Bytecode
> keine Kommentare hat.

Habe mit dem Cachen keinerlei Erfahrung. Meine Anwendung dürfte sich so
im Bereich 200-300 KB am Ende befinden was die PHP Quellcodedateien
betrifft. Ich hoffe ja nicht, dass es in der Größenordnung Probleme
geben wird mit der Größe des Cache.

Rein Prinzipiell wenn ich das richtig verstanden habe müsste ja bei
Caches wie eAccellerator der Quelltext nur einmal geparst werden und
danach wird der Zwischencode aus dem Cache genommen. Hier sollte sich
der Geschwindigkeitsverlust (egal wie hoch) nur auf den ersten Aufruf
beschränken, oder?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Ulf Kadner schrieb:
> Die FAQ dieser Gruppe hat dazu nen Beitrag parat.
>
> 27.7. Schaden Kommentare der Performance?
> http://www.php-faq.de/q/q-stil-kommentare.html

gar nicht gesehen. Danke. :)

Ich denke damit ist es recht eindeutig, dass man die Menge an
Kommentaren für die Performance vernachlässigen kann.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Joerg Behrens schrieb:
>> Hier macht Inline Doku bzw. API Beschreibung bis zu 30% aus. Für den=

>> Parser ist dies nicht relevant und im Bereich der Messungenauigkeit.
>
> bei was macht es 30% aus? Bei deinem Quellcode oder bei der
> Geschwindigkeit des Parsers allgemein?

Quellcode. 30% ist Doku und die restlichen 70% PHP Code.

>> Was aber relvant ist sind Caches des OS welche evt. besser genutzt
>> werden koennen wenn die Dateien kleiner sind bzw. mehr Daten in den
>> Cache passen. Wenn du aber Xcache/APC und co. Verwendest sollte das
>> allerdings auch keine Rolle spielen weil ich mal hoffe das Bytecode
>> keine Kommentare hat.
>
> Habe mit dem Cachen keinerlei Erfahrung. Meine Anwendung dürfte sich =
so
> im Bereich 200-300 KB am Ende befinden was die PHP Quellcodedateien
> betrifft. Ich hoffe ja nicht, dass es in der Größenordnung Probleme=

> geben wird mit der Größe des Cache.
>
> Rein Prinzipiell wenn ich das richtig verstanden habe müsste ja bei
> Caches wie eAccellerator der Quelltext nur einmal geparst werden und
> danach wird der Zwischencode aus dem Cache genommen. Hier sollte sich
> der Geschwindigkeitsverlust (egal wie hoch) nur auf den ersten Aufruf
> beschränken, oder?

Nochmal langsam zum mitschreiben. Dem Parser machen Kommentare nichts
aus.... aber wenn du XX MB/KB an Cache hast... dann passen da nun einmal =

nur N Schripte rein. Sind diese Scripte kleiner (um 30%) passen mehr
hinein. Ich meine hier den Cache welches dein OS benutzt.


Gruss
Joerg


--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Christoph Herrmann schrieb:

> ich wollte mal Fragen, ob es Erfahrungswerte gibt in wie fern sich viel=
e
> Kommentare auf die Laufzeit auswirken?

Nicht schon wieder das Mikrosekunden-Tuning Thema...

Vernachlässige niemals Kommentare zugunsten der Performance. Das Gleich=
e
gilt für Coding-Style (also grob erklärt hübschen Code schreiben an=
statt
fünfzehn Befehle auf einer Zeile). Ein Skript wird auch nicht schneller=
,
wenn alle Variablennamen nur einen Buchstaben lang sind. Wenn überhaupt=

ein Unterschied messbar sein soll, weil der Parser da schneller durch
kommt, dann muss man ihn schon mit hunderttausenden von Zeilen füttern.=


Das Thema hat sich im =DCbrigen sowieso erledigt, sobald du einen
Opcode-Cache wie APC verwendest.

Die nächste Kategorie der "Lass es!" Optimierungen sind Themen wie
"doppelte Anführungszeichen sind aber langsamer als einfache" oder
"Klassen sind langsamer als Funktionen". Hier gibt es zwar einen
Unterschied in der Performance, dieser bewegt sich jedoch im unteren bis
mittleren Mikrosekundenbereich und ist vorläufig irrelevant. Wenn du
irgendwann einen 50-Server-Cluster an der Lastgrenze betreibst, DANN
kannst du darüber nachdenken, wo du noch ein paar Mikrosekunden
einsparen kannst.

Wenn deine Seite langsam wird, dann liegt es NICHT an all diesen Themen.
Da musst du schon völligen Mist bauen und rekursive Aufrufe im Stil vo=
n
Fibonacci-Reihe ohne Ergebniscache mit rekursivem Code ausrechnen. Dein
Programm wird zum Beispiel durchaus langsamer, wenn du ständig
megabytelange Strings hin und her kopierst, aber selbst da wird man es
erst merken, wenn wirklich was ganz böse falsch gemacht wird.

Der zunächst zu betrachtende Flaschenhals bei Performanceproblemen ist
die Datenbankverbindung. Die Latenzzeit einer Datenbankanfrage schlägt
die möglichen Mikrooptimierungen um Längen. Falls du zum Beispiel ein=

SELECT machst und dann in einer Schleife durch das Ergebnis wanderst und
für jeden Eintrag erneut ein SELECT machst, dann ist da der Wurm drin
und du verplemperst Performance im Millisekundenbereich, denn das wäre
auch alles mit einem Join in der ersten Anfrage gegangen. Da ist
tatsächlich lohnendes Optimierungspotential vorhanden.

Falls du die Möglichkeit hast, einen Profiler zu nutzen (XDebug +
CacheGrind), dann ist das dein Freund, wenn du tatsächlich nicht so
herausbekommst, was deine Seite langsam macht. Selbst absolute
PHP-Profis vertun sich mitunter komplett beim Lokalisieren von
Performance-Engpässen.

OLLi

--
The answer is 42.
[Douglas Adams]

Joerg Behrens schrieb:
> Quellcode. 30% ist Doku und die restlichen 70% PHP Code.

Bei mir eher umgekehrt, wenn die ganzen Anwendungsbeispiele und
ausführlichere Beschreibungen enthalten sind. :)

> Nochmal langsam zum mitschreiben. Dem Parser machen Kommentare nichts
> aus.... aber wenn du XX MB/KB an Cache hast... dann passen da nun einmal
> nur N Schripte rein. Sind diese Scripte kleiner (um 30%) passen mehr
> hinein. Ich meine hier den Cache welches dein OS benutzt.

Ok, dann hab ich das soweit kapiert. Wobei ich jetzt noch nicht wüsste
wofür dieser Cache des OS nützlich ist... Einfluss darauf nehmen werde
ich sicherlich nicht können bei meinem Webspace.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Oliver Grätz schrieb:
> Nicht schon wieder das Mikrosekunden-Tuning Thema...

Wer auf Qualität im Quellcode achtet interessiert sich vielleicht auch
dafür, ob sich dies negativ auf die Performance auswirkt. Aber wie
bereits erwähnt wurde ist das hier nicht der Fall.

> Vernachlässige niemals Kommentare zugunsten der Performance. Das Gleiche
> gilt für Coding-Style (also grob erklärt hübschen Code schreiben anstatt
> fünfzehn Befehle auf einer Zeile). Ein Skript wird auch nicht schneller,
> wenn alle Variablennamen nur einen Buchstaben lang sind. Wenn überhaupt
> ein Unterschied messbar sein soll, weil der Parser da schneller durch
> kommt, dann muss man ihn schon mit hunderttausenden von Zeilen füttern.
>
> Das Thema hat sich im Übrigen sowieso erledigt, sobald du einen
> Opcode-Cache wie APC verwendest.
>
> Die nächste Kategorie der "Lass es!" Optimierungen sind Themen wie
> "doppelte Anführungszeichen sind aber langsamer als einfache" oder

[IRONIE]
Sind doppelte nicht schneller solang man nicht die Ersetzungsroutinen
von Variablen nutzt. ;)
[/IRONIE]

> "Klassen sind langsamer als Funktionen". Hier gibt es zwar einen
> Unterschied in der Performance, dieser bewegt sich jedoch im unteren bis
> mittleren Mikrosekundenbereich und ist vorläufig irrelevant. Wenn du
> irgendwann einen 50-Server-Cluster an der Lastgrenze betreibst, DANN
> kannst du darüber nachdenken, wo du noch ein paar Mikrosekunden
> einsparen kannst.
>
> Wenn deine Seite langsam wird, dann liegt es NICHT an all diesen Themen.
> Da musst du schon völligen Mist bauen und rekursive Aufrufe im Stil von
> Fibonacci-Reihe ohne Ergebniscache mit rekursivem Code ausrechnen. Dein
> Programm wird zum Beispiel durchaus langsamer, wenn du ständig
> megabytelange Strings hin und her kopierst, aber selbst da wird man es
> erst merken, wenn wirklich was ganz böse falsch gemacht wird.

Da gebe ich dir vollkommen recht. Nur hab ich halt gedacht, wenn eine
Datei mit Kommentierung um 80% größer ist als ohne, dann braucht der
Parser auch 80% mehr Zeit diese auszulesen. Daher hat mich das doch
bissle interessiert.

> Der zunächst zu betrachtende Flaschenhals bei Performanceproblemen ist
> die Datenbankverbindung. Die Latenzzeit einer Datenbankanfrage schlägt
> die möglichen Mikrooptimierungen um Längen. Falls du zum Beispiel ein
> SELECT machst und dann in einer Schleife durch das Ergebnis wanderst und
> für jeden Eintrag erneut ein SELECT machst, dann ist da der Wurm drin
> und du verplemperst Performance im Millisekundenbereich, denn das wäre
> auch alles mit einem Join in der ersten Anfrage gegangen. Da ist
> tatsächlich lohnendes Optimierungspotential vorhanden.
>
> Falls du die Möglichkeit hast, einen Profiler zu nutzen (XDebug +
> CacheGrind), dann ist das dein Freund, wenn du tatsächlich nicht so
> herausbekommst, was deine Seite langsam macht. Selbst absolute
> PHP-Profis vertun sich mitunter komplett beim Lokalisieren von
> Performance-Engpässen.

Möglichkeit haben bestimmt, aber noch nicht das Wissen wie Profiler und
Debugger mit PHP funktionieren (nur ewig lange Einstellungssachen für
Eclipse bisher gefunden, viel "rumwerkeln" um ein Tool zum Laufen zu
bringen ist aber nichts für mich).

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Oliver Grätz schrieb:

>> Falls du die Möglichkeit hast, einen Profiler zu nutzen (XDebug +
>> CacheGrind), dann ist das dein Freund, wenn du tatsächlich nicht so
>> herausbekommst, was deine Seite langsam macht. Selbst absolute
>> PHP-Profis vertun sich mitunter komplett beim Lokalisieren von
>> Performance-Engpässen.
>
> Möglichkeit haben bestimmt, aber noch nicht das Wissen wie Profiler u=
nd
> Debugger mit PHP funktionieren (nur ewig lange Einstellungssachen für=

> Eclipse bisher gefunden, viel "rumwerkeln" um ein Tool zum Laufen zu
> bringen ist aber nichts für mich).

Du installierst XDebug auf dem Server (Modul in Extensionsverzeichnis
packen und php.ini nach Doku anpassen) und aktivierst den in XDebug
mitgelieferten Profiler. Dann rufst du die Seite ab. Dann deaktivierst
du den Profiler bitte sofort wieder in der php.ini, denn der kostet
WIRKLICH Performance. Der eine Abruf wird dir dann wahrscheinlich (bei
etwas größeren als Miniprojekten) eine gigantische Datei im
Multimegabyte-Bereich mit Profilinginfos erzeugt haben. Die kopierst du
dorthin, wo du sie analysieren möchtest. Dazu nimmst du zum Beispiel
unter Linux KCacheGrind und unter Windows WinCacheGrind. Du siehst da
dann haarklein, wieviel Zeit welche Aufrufe benötigt haben. Vor allem
siehst du auch, welche Funktionen am häufigsten aufgerufen werden. Das
hilft dir dabei, dort zu optimieren, wo es auch was bringt.

OLLi

--
"Wenn du 'ne Reißzwecke hast, bastel ich dir 'ne Scud-Rakete."
[Gilmore Girls]

Christoph Herrmann schrieb:
> Joerg Behrens schrieb:
>> Quellcode. 30% ist Doku und die restlichen 70% PHP Code.
>
> Bei mir eher umgekehrt, wenn die ganzen Anwendungsbeispiele und
> ausführlichere Beschreibungen enthalten sind. :)
>
>> Nochmal langsam zum mitschreiben. Dem Parser machen Kommentare nichts =

>> aus.... aber wenn du XX MB/KB an Cache hast... dann passen da nun einm=
al
>> nur N Schripte rein. Sind diese Scripte kleiner (um 30%) passen mehr
>> hinein. Ich meine hier den Cache welches dein OS benutzt.
>
> Ok, dann hab ich das soweit kapiert. Wobei ich jetzt noch nicht wüsst=
e
> wofür dieser Cache des OS nützlich ist... Einfluss darauf nehmen we=
rde
> ich sicherlich nicht können bei meinem Webspace.

Die hier angesprochenen Caches sind solche auf Dateisystemebene. Bei
Windows hat zum Beispiel NTFS einen Cache. =D6ffnest du eine Datei, die d=
u
kurz vorher schon einmal geöffnet hast, dann kommt sie beim zweiten Mal=

nicht von der Platte, sondern aus diesem Cache. Da der in der Größe
begrenzt ist, passen ohne Kommentare mehr Quellcodedateien hinein.

Das Thema wird aber durch Verwenden eines Opcode-Caches irrelevant, weil
dann die im Cache gespeicherten Dateien nach kurzer Zeit nicht die
Quellcodes sind, sondern die bereits kompilierten Skripte, und in denen
gibt es keine Kommentare mehr. Außerdem wird bei einem Opcode-Cache
meist von diesem selbst ein Cache im RAM gehalten, der Effekt des
OS-Caches wird also ausgenullt.

OLLi

--
"No more Mr. Nice Gaius!!!"
[Baltar on Battlestar Galactica 107]

Oliver Grätz schrieb:
> Du installierst XDebug auf dem Server (Modul in Extensionsverzeichnis
> packen und php.ini nach Doku anpassen) und aktivierst den in XDebug
> mitgelieferten Profiler. Dann rufst du die Seite ab. Dann deaktivierst
> du den Profiler bitte sofort wieder in der php.ini, denn der kostet
> WIRKLICH Performance. Der eine Abruf wird dir dann wahrscheinlich (bei
> etwas größeren als Miniprojekten) eine gigantische Datei im
> Multimegabyte-Bereich mit Profilinginfos erzeugt haben. Die kopierst du
> dorthin, wo du sie analysieren möchtest. Dazu nimmst du zum Beispiel
> unter Linux KCacheGrind und unter Windows WinCacheGrind. Du siehst da
> dann haarklein, wieviel Zeit welche Aufrufe benötigt haben. Vor allem
> siehst du auch, welche Funktionen am häufigsten aufgerufen werden. Das
> hilft dir dabei, dort zu optimieren, wo es auch was bringt.

Werde ich mir auf jeden Fall mal anschauen sobald die Sachen soweit
fertig sind und dann nach Performancebremsen suchen. Danke.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Joerg Behrens schrieb:
>> Quellcode. 30% ist Doku und die restlichen 70% PHP Code.
>
> Bei mir eher umgekehrt, wenn die ganzen Anwendungsbeispiele und
> ausführlichere Beschreibungen enthalten sind. :)

Und was spricht dagegen, eine Readme-Datei beizulegen, in die du die
Dokumentation ausgliederst?

--
Blubb

Dirk Sohler schrieb:
> Und was spricht dagegen, eine Readme-Datei beizulegen, in die du die
> Dokumentation ausgliederst?

Dass damit alle Vorteile einer API Dokumentation flöten gehen, was für
mich inakzeptable ist.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Dirk Sohler wrote:
> Christoph Herrmann schrieb:
>
>>Joerg Behrens schrieb:
>>
>>>Quellcode. 30% ist Doku und die restlichen 70% PHP Code.
>>
>>Bei mir eher umgekehrt, wenn die ganzen Anwendungsbeispiele und
>>ausführlichere Beschreibungen enthalten sind. :)
>
>
> Und was spricht dagegen, eine Readme-Datei beizulegen, in die du die
> Dokumentation ausgliederst?

Das verfehlt ja eigentlich den Sinn der Inline-Doku, direkt aus dem
Programm die Doku zu erzeugen. Inline-Doku hat größere Chancen gepflegt
zu werden, als eine Readme-Datei. OK. Anwendungsbeispiele würde ich
vielleicht auch extra packen, aber das ist reine Geschmackssache.
Eine andere Möglichkeit wäre noch, per Parser die ganzen Kommentare zu
entfernen, und diese Version dann auf den Server zu deployen. Solange
man reinen PHP-Code benutzt, ist der recht einfach zu erstellen.

Stefan Dreyer schrieb:
> Das verfehlt ja eigentlich den Sinn der Inline-Doku, direkt aus dem
> Programm die Doku zu erzeugen. Inline-Doku hat größere Chancen gepflegt
> zu werden, als eine Readme-Datei. OK. Anwendungsbeispiele würde ich
> vielleicht auch extra packen, aber das ist reine Geschmackssache.

Wenn die Anwendungsbeispiele in der Dokumentation sind, sind diese auch
später bei der Beschreibung einer Klasse vorhanden. Des weiteren sind
gerade hier öfters Änderungen nach Quellcodeanpassungen von Nöten und
ein schneller Zugriff umso wichtiger.

> Eine andere Möglichkeit wäre noch, per Parser die ganzen Kommentare zu
> entfernen, und diese Version dann auf den Server zu deployen. Solange
> man reinen PHP-Code benutzt, ist der recht einfach zu erstellen.

Habe ich auch schon daran gedacht. Müsste ich dann schauen (oder weiß es
jemand?) ob der PHPDocumentor so etwas kann.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Oliver Grätz schrieb:
> Christoph Herrmann schrieb:
>> Oliver Grätz schrieb:
>
>>> Falls du die Möglichkeit hast, einen Profiler zu nutzen (XDebug +
>>> CacheGrind), dann ist das dein Freund, wenn du tatsächlich nicht so
>>> herausbekommst, was deine Seite langsam macht. Selbst absolute
>>> PHP-Profis vertun sich mitunter komplett beim Lokalisieren von
>>> Performance-Engpässen.
>> Möglichkeit haben bestimmt, aber noch nicht das Wissen wie Profiler und
>> Debugger mit PHP funktionieren (nur ewig lange Einstellungssachen für
>> Eclipse bisher gefunden, viel "rumwerkeln" um ein Tool zum Laufen zu
>> bringen ist aber nichts für mich).
>
> Du installierst XDebug auf dem Server (Modul in Extensionsverzeichnis
> packen und php.ini nach Doku anpassen) und aktivierst den in XDebug
> mitgelieferten Profiler. Dann rufst du die Seite ab. Dann deaktivierst
> du den Profiler bitte sofort wieder in der php.ini, denn der kostet
> WIRKLICH Performance.

Sollte hier nicht dl() gute Dienste leisten können?
Ich stelle mir das mal-eben-ein-und-ausschalten gerade bei öfter
besuchten Seiten etwas holprig vor.

regards,
Jens

On Wed, 28 Nov 2007 13:57:35 +0100 Oliver Grätz wrote:
> Die nächste Kategorie der "Lass es!" Optimierungen sind Themen wie
> "doppelte Anführungszeichen sind aber langsamer als einfache" oder
> "Klassen sind langsamer als Funktionen". [...]

> [...] Falls du zum Beispiel ein SELECT machst und dann in einer
> Schleife durch das Ergebnis wanderst und für jeden Eintrag erneut ein
> SELECT machst, dann ist da der Wurm drin und du verplemperst
> Performance im Millisekundenbereich, denn das wäre auch alles mit
> einem Join in der ersten Anfrage gegangen.

Gerade bei strikt objektorientiertem Design passiert einem _so_ etwas
aber relativ schnell...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan, so gut wie das Naschen. Da werden Kinderträume wahr!
(Sloganizer)

Jens Himmelrath schrieb:
> Oliver Grätz schrieb:
>> Du installierst XDebug auf dem Server (Modul in Extensionsverzeichnis
>> packen und php.ini nach Doku anpassen) und aktivierst den in XDebug
>> mitgelieferten Profiler. Dann rufst du die Seite ab. Dann deaktivierst=

>> du den Profiler bitte sofort wieder in der php.ini, denn der kostet
>> WIRKLICH Performance.
>
> Sollte hier nicht dl() gute Dienste leisten können?
> Ich stelle mir das mal-eben-ein-und-ausschalten gerade bei öfter
> besuchten Seiten etwas holprig vor.

dl() ist "deprecated" und in PHP6 wird es dl() im Apache-Modul nicht
mehr geben. Davon abgesehen ist es natürlich aktuell noch eine Alternat=
ive.

OLLi

--
"Take them to the dungeons. Not the nice ones!"
[HYPERDRIVE 102]

Jens Himmelrath schrieb:
> Oliver Grätz schrieb:
>> Christoph Herrmann schrieb:
>>> Oliver Grätz schrieb:
>>>> Falls du die Möglichkeit hast, einen Profiler zu nutzen (XDebug +
>>>> CacheGrind), dann ist das dein Freund, wenn du tatsächlich nicht so
>>>> herausbekommst, was deine Seite langsam macht. Selbst absolute
>>>> PHP-Profis vertun sich mitunter komplett beim Lokalisieren von
>>>> Performance-Engpässen.
>>> Möglichkeit haben bestimmt, aber noch nicht das Wissen wie Profiler und
>>> Debugger mit PHP funktionieren (nur ewig lange Einstellungssachen für
>>> Eclipse bisher gefunden, viel "rumwerkeln" um ein Tool zum Laufen zu
>>> bringen ist aber nichts für mich).
>> Du installierst XDebug auf dem Server (Modul in Extensionsverzeichnis
>> packen und php.ini nach Doku anpassen) und aktivierst den in XDebug
>> mitgelieferten Profiler. Dann rufst du die Seite ab. Dann deaktivierst
>> du den Profiler bitte sofort wieder in der php.ini, denn der kostet
>> WIRKLICH Performance.
>
> Sollte hier nicht dl() gute Dienste leisten können?
> Ich stelle mir das mal-eben-ein-und-ausschalten gerade bei öfter
> besuchten Seiten etwas holprig vor.

Oh, nagut: "Xdebug MUST be loaded as a Zend extension"
Aber immerhin gibt es "xdebug.profiler_enable_trigger", aber das schützt
öffnet ja Tür und Tor für DoS-Attacken, wenn man es nicht schnell
wieder deaktiviert.
Gibt es da keine elegantere Methode?

regards,
Jens, der Xdebug sowieso schon seit Monaten mal ausprobieren wollte.

Jens Himmelrath schrieb:
> Jens Himmelrath schrieb:
>> Oliver Grätz schrieb:
>>> Christoph Herrmann schrieb:
>>>> Oliver Grätz schrieb:
>>>>> Falls du die Möglichkeit hast, einen Profiler zu nutzen (XDebug +
>>>>> CacheGrind), dann ist das dein Freund, wenn du tatsächlich nicht so
>>>>> herausbekommst, was deine Seite langsam macht. Selbst absolute
>>>>> PHP-Profis vertun sich mitunter komplett beim Lokalisieren von
>>>>> Performance-Engpässen.
>>>> Möglichkeit haben bestimmt, aber noch nicht das Wissen wie Profiler und
>>>> Debugger mit PHP funktionieren (nur ewig lange Einstellungssachen für
>>>> Eclipse bisher gefunden, viel "rumwerkeln" um ein Tool zum Laufen zu
>>>> bringen ist aber nichts für mich).
>>> Du installierst XDebug auf dem Server (Modul in Extensionsverzeichnis
>>> packen und php.ini nach Doku anpassen) und aktivierst den in XDebug
>>> mitgelieferten Profiler. Dann rufst du die Seite ab. Dann deaktivierst
>>> du den Profiler bitte sofort wieder in der php.ini, denn der kostet
>>> WIRKLICH Performance.
>> Sollte hier nicht dl() gute Dienste leisten können?
>> Ich stelle mir das mal-eben-ein-und-ausschalten gerade bei öfter
>> besuchten Seiten etwas holprig vor.
>
> Oh, nagut: "Xdebug MUST be loaded as a Zend extension"
> Aber immerhin gibt es "xdebug.profiler_enable_trigger", aber das schützt
> öffnet ja Tür und Tor für DoS-Attacken, wenn man es nicht schnell
> wieder deaktiviert.
> Gibt es da keine elegantere Methode?

Sollte natürlich ohne "schützt" rausgehen.

regards,
Je-"Heute mal Ingrid"-ns

Stefan Froehlich schrieb:
> On Wed, 28 Nov 2007 13:57:35 +0100 Oliver Gr=C3=A4tz wrote:
>> Die n=C3=A4chste Kategorie der "Lass es!" Optimierungen sind Themen wi=
e
>> "doppelte Anf=C3=BChrungszeichen sind aber langsamer als einfache" ode=
r
>> "Klassen sind langsamer als Funktionen". [...]
>
>> [...] Falls du zum Beispiel ein SELECT machst und dann in einer
>> Schleife durch das Ergebnis wanderst und f=C3=BCr jeden Eintrag erneut=
ein
>> SELECT machst, dann ist da der Wurm drin und du verplemperst
>> Performance im Millisekundenbereich, denn das w=C3=A4re auch alles mit=

>> einem Join in der ersten Anfrage gegangen.
>
> Gerade bei strikt objektorientiertem Design passiert einem _so_ etwas
> aber relativ schnell...

Ich sagte ja auch, dass man dort zuerst gucken soll!?

Die Aussage zu Beginn, dass man nicht wegen "Funktionen sind schneller
als Klassen" auf Klassenverzicht hin optimieren soll, hat damit nur
indirekt etwas zu tun. Ein beim Datenbankzugriff auftretendes
Performance-Problem ist schlie=C3=9Flich kein Grund, dann die Klassen zu
streichen, sondern sie so zu ver=C3=A4ndern, dass die Datenbank besser
genutzt wird. Bei einem guten objektorientierten Design ist es in der
Regel dann auch leichter, so ein Problem aus der Welt zu schaffen, ohne
das Interface zu =C3=A4ndern.

OLLi

--
The programmer's nat'l anthem is 'AAAAAAAAHHHHHHHH'
[Weinberg]

Stefan Dreyer <Stefan.Dreyer [at] ddnetservice.net> wrote:

> Das verfehlt ja eigentlich den Sinn der Inline-Doku, direkt aus dem
> Programm die Doku zu erzeugen. Inline-Doku hat größere Chancen gepflegt
> zu werden, als eine Readme-Datei.

Man könnte aus den php-Files auch automatisiert eine runtime-Version
generieren, die keine Kommentare enthält.

meinjanur
Konni
--
Inzwischen ohne Signatur

Konni Scheller schrieb:
> Man könnte aus den php-Files auch automatisiert eine runtime-Version
> generieren, die keine Kommentare enthält.

Man könnte oder man kann? Also sprich gibt es konkrete
Lösungen/Software, die so etwas automatisiert erledigen kann?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Konni Scheller schrieb:
>> Man könnte aus den php-Files auch automatisiert eine runtime-Version=

>> generieren, die keine Kommentare enthält.
>
> Man könnte oder man kann? Also sprich gibt es konkrete
> Lösungen/Software, die so etwas automatisiert erledigen kann?

Ein paar Zeilen Regex und das war es schon. Das ganze Verpackt in deinen =

Installer/Updater. Alternativ ein "php -w script".

Gruss
Joerg


--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Christoph Herrmann <herrmann [at] dragonprojects.de> wrote:

> Man könnte oder man kann? Also sprich gibt es konkrete
> Lösungen/Software, die so etwas automatisiert erledigen kann?

Ich weiß nicht, ob du das kannst :-)

Ich finde es sehr trivial, das selbst zu programmieren.

Servus,
Konni
--
Inzwischen ohne Signatur

Konni Scheller schrieb:
> Ich weiß nicht, ob du das kannst :-)
>
> Ich finde es sehr trivial, das selbst zu programmieren.

ich nicht mal so sehr, weil ich mich immer schwer tue mit Regex Sachen.
:) In vielen Dingen strebe ich eher dazu das Rad nicht neu zu erfinden,
vor allem weil ich für sowas triviales nicht unbedingt Zeit investieren
will, sondern in der Zeit lieber andere sinnvollere Features implementier.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

On Fri, 30 Nov 2007 02:06:31 +0100 Konni Scheller wrote:
> > Man könnte oder man kann? Also sprich gibt es konkrete
> > Lösungen/Software, die so etwas automatisiert erledigen kann?

> Ich finde es sehr trivial, das selbst zu programmieren.

Trivial wird es vor allem, sobald man einmal ueber die Funktion
token_get_all() gestolpert ist.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Im siebten Himmel. Mit Stefan. Ein gelassenes Vergnügen!
(Sloganizer)

Joerg Behrens schrieb:
> Christoph Herrmann schrieb:
>...

>> Man könnte oder man kann? Also sprich gibt es konkrete
>> Lösungen/Software, die so etwas automatisiert erledigen kann?
>
> Ein paar Zeilen Regex und das war es schon. Das ganze Verpackt in deinen
> Installer/Updater. Alternativ ein "php -w script".
>

Naja so leicht wirds auch nicht sein, oder? Ich meine, du müsstest quasi
nen PHP Parser in Regex schreiben, um auch wirklich NUR Kommentare zu
filtern, müsstest du schon die komplette zulässige PHP Syntax in eine
Regex packen, viel Spaß! Sicher kann man einige Einschränkungen
vornehmen, indem man nur die Syntaxelemente betrachtet, die mit
Kommentaren zu tun haben, aber ob man da alle Sonderfälle abdecken kann?

Oder hab ich jetzt was falsch verstanden, bei dem was du machen willst?

Dieter

> Gruss
> Joerg
>
>

Dieter Hansen schrieb:
> Naja so leicht wirds auch nicht sein, oder? Ich meine, du müsstest quasi
> nen PHP Parser in Regex schreiben, um auch wirklich NUR Kommentare zu
> filtern, müsstest du schon die komplette zulässige PHP Syntax in eine
> Regex packen, viel Spaß! Sicher kann man einige Einschränkungen
> vornehmen, indem man nur die Syntaxelemente betrachtet, die mit
> Kommentaren zu tun haben, aber ob man da alle Sonderfälle abdecken kann?
>
> Oder hab ich jetzt was falsch verstanden, bei dem was du machen willst?

Ich denke er meinte einfach alles rausnehmen was hinter "//" oder
zwischen "/*" und "*/" steht. Aber so einfach ist es denk ich nicht. Vor
allem wenn man solche Konstrukte in irgendwelchen Strings verwendet. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Konni Scheller schrieb:
>> Man könnte aus den php-Files auch automatisiert eine runtime-Version=

>> generieren, die keine Kommentare enthält.
>
> Man könnte oder man kann? Also sprich gibt es konkrete
> Lösungen/Software, die so etwas automatisiert erledigen kann?
>
Immer wieder lustig, wie wenig die Leute in die PHP-Doku gucken:

http://de.php.net/manual/en/ref.tokenizer.php

Man beachte insbesondere das Code-Beispiel...

OLLi

--
Mal: "How drunk was I last night?"
Jayne: "I don't know. I passed out."
[firefly 06]

Oliver Grätz schrieb:
> Immer wieder lustig, wie wenig die Leute in die PHP-Doku gucken:

wie soll man dahin denn kommen, wenn man es noch nicht kennt. ;)

> http://de.php.net/manual/en/ref.tokenizer.php
>
> Man beachte insbesondere das Code-Beispiel...

Joa, schon das Beispiel macht ja ziemlich das, was ich brauche, danke. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Dieter Hansen <dieter.hansen [at] noname.none> wrote:

> Naja so leicht wirds auch nicht sein, oder? Ich meine, du müsstest quasi
> nen PHP Parser in Regex schreiben, um auch wirklich NUR Kommentare zu
> filtern, müsstest du schon die komplette zulässige PHP Syntax in eine
> Regex packen, viel Spaß! Sicher kann man einige Einschränkungen
> vornehmen, indem man nur die Syntaxelemente betrachtet, die mit
> Kommentaren zu tun haben, aber ob man da alle Sonderfälle abdecken kann?

Man kann natürlich ein kompliziertes RegEx schreiben, das auch Fälle wie

echo " /* ich veräpple jetzt den Parser */";

berücksichtigt.

Man kann aber auch sowas von Hand machen.

Servus,
Konni
--
Inzwischen ohne Signatur

Christoph Herrmann wrote:
>Oliver Grätz schrieb:
>> Immer wieder lustig, wie wenig die Leute in die PHP-Doku gucken:
>
>wie soll man dahin denn kommen, wenn man es noch nicht kennt. ;)
>
>> http://de.php.net/manual/en/ref.tokenizer.php
>>
>> Man beachte insbesondere das Code-Beispiel...
>
>Joa, schon das Beispiel macht ja ziemlich das, was ich brauche, danke. :)

Ob 'brauchen' hier das richtige Wort ist? Ich weiß ja nicht, wieviel
Dokumentation Du schreibst, aber selbst bei einer 3MB großen
Quelltext-Datei mit über 100.000 Zeilen, von denen 90% einzelne
Kommentare sind (also 1 Zeile Code auf 9 Zeilen, welche *jeweils* von
/* und */ eingeschlossen sind) gibt php -w ohne nennenswerte
Verzögerung ein Ergebnis aus.

Also - die Zeit, welche Du für diesbezügliche Optimierungen aufbringt,
kannst Du sicherlich besser nutzen.

Und selbst wenn, was spricht denn gegen `php -w`?

schöne grüße, steffen

steffen horst schrieb:
> Ob 'brauchen' hier das richtige Wort ist? Ich weiß ja nicht, wieviel
> Dokumentation Du schreibst, aber selbst bei einer 3MB großen
> Quelltext-Datei mit über 100.000 Zeilen, von denen 90% einzelne
> Kommentare sind (also 1 Zeile Code auf 9 Zeilen, welche *jeweils* von
> /* und */ eingeschlossen sind) gibt php -w ohne nennenswerte
> Verzögerung ein Ergebnis aus.
>
> Also - die Zeit, welche Du für diesbezügliche Optimierungen aufbringt,
> kannst Du sicherlich besser nutzen.

ich würde es nur nutzen, wenn es Probleme bei der Performance gibt als
Test, ob ohne Kommentare ein besseres Ergebnis erzielt werden kann. Von
daher wirklich "brauchen" noch nicht. Aber besser etwas haben und nicht
brauchen als umgekehrt. :) Noch ist es eher reines Interesse.

> Und selbst wenn, was spricht denn gegen `php -w`?

Ich denke mal, es handelt sich hier um den Aufruf des Skriptes per
Kommandozeile. Was macht das -w denn? Habe auf die schnelle gerade keine
Antwort darauf gefunden.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann wrote:
>steffen horst schrieb:
>> Ob 'brauchen' hier das richtige Wort ist? Ich weiß ja nicht, wieviel
>> Dokumentation Du schreibst, aber selbst bei einer 3MB großen
>> Quelltext-Datei mit über 100.000 Zeilen, von denen 90% einzelne
>> Kommentare sind (also 1 Zeile Code auf 9 Zeilen, welche *jeweils* von
>> /* und */ eingeschlossen sind) gibt php -w ohne nennenswerte
>> Verzögerung ein Ergebnis aus.
>>
>> Also - die Zeit, welche Du für diesbezügliche Optimierungen aufbringt,
>> kannst Du sicherlich besser nutzen.
>ich würde es nur nutzen, wenn es Probleme bei der Performance gibt als
>Test, ob ohne Kommentare ein besseres Ergebnis erzielt werden kann. Von
>daher wirklich "brauchen" noch nicht. Aber besser etwas haben und nicht
>brauchen als umgekehrt. :) Noch ist es eher reines Interesse.

Ich verstehe was Du meinst, aber Du musst es so hinnehmen: hier liegt
wirklich kein Optimierungspotential. Deine Quelltexte sollten weit
kleiner als 300kb groß sein (getestet ist das 10-fache) und es kommen
sicherlich nicht auf jede Zeile Code 9 einzelne Kommentare..

>> Und selbst wenn, was spricht denn gegen `php -w`?
>Ich denke mal, es handelt sich hier um den Aufruf des Skriptes per
>Kommandozeile. Was macht das -w denn? Habe auf die schnelle gerade keine
>Antwort darauf gefunden.

Dann führe das aus: php --help und staune.

Schöne Grüße, Steffen

steffen horst schrieb:
> Ich verstehe was Du meinst, aber Du musst es so hinnehmen: hier liegt
> wirklich kein Optimierungspotential. Deine Quelltexte sollten weit
> kleiner als 300kb groß sein (getestet ist das 10-fache) und es kommen
> sicherlich nicht auf jede Zeile Code 9 einzelne Kommentare..

definiere weit :) Die Basis des Projektes ist um die 200KB groß. Das
Projekt dass darauf aufbaut dürfte dann auch um die 100KB sein. Aber
klar, wenn es selbst bei 3MB keinen groß messbaren Unterschied gibt.
Dann ist das eher sinnlos.

> Dann führe das aus: php --help und staune.

Probier ich dann bei Gelegenheit. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> wie soll man dahin denn kommen, wenn man es noch nicht kennt. ;)

Indem man zwei Minuten sucht!? Ich war mir auch nur lose im Klaren
darüber, dass es irgendwas für Code-Parsing schon gibt. Schließlich=

arbeiten eine Reihe von Projekten wie phpDocumentor oder dieses Teil,
was WebServices aus DocComments baut, damit...

>> http://de.php.net/manual/en/ref.tokenizer.php
>>
>> Man beachte insbesondere das Code-Beispiel...
>
> Joa, schon das Beispiel macht ja ziemlich das, was ich brauche, danke. =
:)

Dass man das aus Performancegründen nicht braucht, war schon lange klar=
=2E
Aber "nicht brauchen" heißt ja nicht "nicht wollen"...

OLLi

--
"Please tell me you found a coffee bar."
[Jack on LOST 113]