file_exists oder filemtime - Optimierungsblödsinn

Ausgehend von einer Bemerkung einer der Smarty - Entwickler der angab, man werde nun filemtime statt file_exists einsetzen hat man in der deutschen Fraktion nun langsam auswuchernde Test's damit veranstaltet.
Is_file ist auch eine Option allerdings sind die einsetzbaren Wrapper nicht identisch mit den anderen Methoden.

Ausufernd ist es nun deshalb weil niemand gecheckt hat warum und wieso Smarty das macht.

Smarty schreibt als Kommentar im Quelltext seiner Klasse

 Smarty deliberately uses @filemtime() over file_exists() and filemtime() in some places. Reasons include

                - @filemtime() is almost twice as fast as using an additional file_exists()

                - between file_exists() and filemtime() a possible race condition is opened,

                  which does not exist using the simple @filemtime() approach.

filemtime taucht als Wort bei Smarty 41 mal in 15 Scripten auf und es geht immer darum den Timestamp einer Datei zu ermitteln.
Das ist eine Angabe die Smarty laufend benötigt um z.B. den Ablauf von Cachedateien zu ermitteln oder einen Vergleich Template-Quelldatei und compilierte Datei vornehmen zu können um einen eventuell notwendigen Bedarf einer Neucompilierung festzustellen.

Die Zeitnachteile dieser Methode der dann eintritt, wenn eine Datei nicht vorhanden ist nimmt man bewusst in Kauf, da dies relativ selten vorkommt.
Die Zeitvorteile überwiegen also sehr stark und deshalb ist es richtig.

Und genau deshalb ist es falsch das als Wohltat für andere Teile von Cmsms anzusehen.


Da heißt die bessere Alternative für file_exists ist is_file, wobei is_file nur auf lokal einsetzbar ist und im Rahmen der Rechte.
Mit file_exists sind auch Zugriffe auf eine URL möglich.
Aber genau das sollte man aus Sicherheitsgründen eben nicht einsetzen.

Der Tausch von file_exists nach is_file in den reinen Cmsms Teilen (also ohne Smarty) bringt eine Erhöhung des Speed um 13% und das ist doch recht ansehnlich.
Die kürzeste Transactionzeit reduziert sich sogar von 0.34 Sekunden auf 0.11 Sekunden.

Und damit dürfte klar sein  was man machen sollte.

Optimierer sollten sich immer darüber im klaren sein warum jemand eine bestimmte Optimierung einsetzt und ob es gut für einem selbst ist.

Und man sollte immer unter Last prüfen (Siege) ob es sich lohnt.

Auf der anderen Seite wird einem immer mehr klar das solche Gedanken dem eigentichen Developer offenbar völlig fremd sind.
Betreibt man Entwicklung so wie es bis jetzt bei Cmsms geschieht ist es kein Wunder das man eine lame duck gezüchtet hat.