Grundlagen

[Christoph Zurnieden]

Hi,

Ich dachte eigentlich, das es genau das ist, was man braucht, denn die Alternative wäre "funktioniert erstmal nicht", denn entweder klappt es oder nicht; ein bischen schwanger gibt es nicht.

Ja Christoph, viele Wege führen nach Rom.

Ich dachte eigentlich immer: alle?

In diesem Sinne finde ich Deinen Vergleich der Schwangerschaft unpassend, denn funktionieren werden viele Wege. Aber beim Beispiel bleibend scheint es Schwangerschaften zu geben die länger als neun Monate brauchen; oder anders ausgedrück: Manch eine Reise hat die Stationen Paris - Erkner - Rom ;)

Ja, mitunter ist die Landkarte, die Entscheidung, der Algorithmus falsch.

Allgemein ist mir Deine Denkweise zu schroff und der vermutete -Beweis durch Kontraposition-

Nein, das war's noch nicht einmal, das war schlichte Polemik. Mitunter laß ich mich da hinreißen, bitte um Entschuldigung.

dem Verständnis, was gemeint ist, nicht zuträglich. Mir geht es nicht um das direkte Gegenteil von "[erstmal ]funktionieren" zu "[erstmal ]nicht funktionieren" hin, sondern nur um das Wie mit der Grundlage "funktionieren". Wenn Du so willst: "funktioniert" <> "funktioniert bestmöglich"

Dann hängt aber alles an Deiner Definition von "bestmöglich".
Es ist wie schon erwähnt, das Gleiche wie beim Minimax-Prinzip. _Entweder_ maximierst Du den Gewinn _oder_ minimierst die Kosten, beides _gleichzeitig_ geht einfach nicht aber das ist genau das, was Du hier versuchst.

Das erarbeiten einer solchen Basis ist überaus Zeitaufwändig.

Rein theoretisch sogar unendlich, denn Du mußt Dein Wissen ja ständig uptodate halten: für jede Architektur, Sprachversion und Erkenntnisse der Informationstechnik.
Ich mein: Du weißt ganz genau, wann Dir der Kernelscheduler dazwischenhaut? Ob das stört oder nicht? Für jeden Kernel auf jeder Architektur, die der Mensch geschaffen hat und noch schaffen wird? Nur ein kleines Teil von sehr vielen.

Und genau da geht Dein Argument fehl: Ist die Basis da, verbraucht sie keinerlei Zeit, sondern im Gegenteil wird Zeit für nötige Optimierungen erspart.

Ich behaupte hier aber nunmal, das _solche_ Optimierungen nicht nötig sind. Wenn Deine Hardware bereits an einem OPunkt ist, das die 1-3% Geschwindigkeitsverbesserung tatsächlich nötig werden, dann reicht die Hardware einfach nicht mehr.
Es gibt Optimierungen, die bringen 'was: reduziertes I/O, reduzierte DB-Zugriffe, ein besserer Sortieralgorithmus, usw,
das bringt Geschwnidigkjeitssteigerungen im exponetiellen Bereich. Aber auch reduzierte Codemenge (= weniger potentielle Bugs!) bringt etwas: es funktioniert schneller (das Programm ist in kürzerer Zeit entwickelt bzw hat weniger Bugs): R&D ist billiger.
Auch können spezielle Algorithem dazu führen, das, obwohl sie einzeln betrachtet deutlich langsamer sind als andere, parallel abgearbeitet werden können, ich kann ein Mehrprozessorsystem ausnutzen.

Hier und da einen Zyklus einzusparen bringt vieleicht etwas bei einem Computerspiel, denn mehr Frames/Sekunde ist aus mir nicht ganz erfindlichen Gründen wohl ein gutes Verkaufsargument.
Im Embeded Bereich der Endverbraucher (Handhelds) ist Geschwindigkeit der Ausführung auch kaum noch ein Problem, da ist es mit deutlicher Mehrheit der begrenzte Speicher.
BTW: in Handhelds sind meist RISC-Prozessoren verbaut, kennst Du Dich mit deren Gepflogenheiten ebenfalls aus?

Vor einer Überpüfung habe ich geglaubt, die neu Funktion scandir() sei eine Erleichterung. Jetzt weiß ich es besser.

Ja, ist es denn komplizierter damit?

Vor einer Überprüfung habe ich geglaubt, mit fgets() bin ich gut bedien. Jetzt weiß ich es besser.

Was gibt es denn besseres?

Vor einer Überpüfung habe ich geglaubt, mit count() in einer Schleife arbeiten zu wollen. Jetzt weiß ich es besser...

Was ist daran verkehrt?

Hast Du schon mal den Code von einem Vorgänger durcharbeiten sollen?

Ja. Aber was hat das hiermit zu tun?

Hast Du dann auch schon mal mit der hablen Zeit -das Selbe- erledigt?

Du meinst: "Mein lieber Mann, was für ein Murks, das habe ich ja schneller neu gebaut als repariert!"?
Ja, das kam schon mal vor.
Aber da nur für pieselige 100% Geschwindigkeitssteigerung dranzugehen - nein, das bringt nix, das zahlt keiner. Das Risiko nicht zu vergessen, das man durch jede(!) Änderung auch neue Bugs einbauen kann!
Wenn ich jedoch sehe, das ich auch bei konservativster Kosten/Nutzen/Risiko Kalkulation Gewinn machen kann (Anderer Algorithmus verringert Komplexität im Code und/oder macht das 10-100x schneller), dann geh ich da ran, das kann ich auch gut verkaufen.

Was wenn ein Kunde mal die Kosten für ein Gutachten nicht scheut?

Wer macht das Gutachten und vor allem: worauf hin? Doch höchstens daraufhin, das die Vorgaben nicht eingehalten wurden und ob da Sicherheitsmängel zu finden sind. Was noch?

Was war noch mal mein Anliegen? ;)

Geschwindigkeitsoptimierung, ja.
Stehen da Geschwindigkeitsvorgaben in den Specs? Nein? Dann muß Dich das auch nicht kümmern.
Stehen da welche drin? Hast Du die eingehalten wenn auch nicht ein Promille mehr, obwohl theoretisch möglich? Dann muß Dich das auch nicht kümmern.

Nur wenn das Dein einziger Kunde ist, hast Du ein Problem, das ist aber keineswegs informationstechnischer Art, sondern ökonomischer.

Diese Einstellung hat bei kleinen Leuten mit kleinem Budget Berechtigung.

Da schon mal überhaupt nicht. Das teuerste ist bei Softwareentwicklung Zeit und Microoptimierung frißt Zeit, die kannst Du stets anderweitig _viel_ gewinnbringender einsetzen.

Mit "Diese Einstellung hat bei kleinen Leuten mit kleinem Budget Berechtigung." stimme ich Dir zu und fange mir "Da schon mal überhaupt nicht." ein. Jetzt wird mir Deine Logik zu hoch.

Dann war es ein Mißverständnis, für mich sah es tatsächlich so merkwürdig aus.
Allerdings: auch mit großem Budget würde ich das Geld für andere Zwecke als Microoptimierung einsetzen. Aber ich habe auch noch nie eine Softwareentwicklung mit großem Budget gesehen, selbst bei Microsoft nicht, wenn man das in Relation setzt. Das gibt es vielleicht bei Geheimdiensten von Staaten mit großem BIP zum Zwecke des Schlüsselknackens o.ä., aber nicht in der Wirtschaft.

So ein Budget ist immer zu klein für den Entwickler und immer zu groß für den Geldgeber.

Ach, Du möchtest beides? Sauberen _und_ geschwindigkeitsoptimierten Code? Das funktoniert nicht, da ist das Minimax-Gesetz gegen.

Hm, google half mir nicht weiter. Bitte gib eine Quelle an, damit ich die gleiche Grundlage habe. Ich kenne kein Minimax-Gesetz.

Steht's nicht bei Google gibt's da nicht?
Ja, das kann passieren, ist aber auch sehr unwahrscheinlich.
Wie auch hier:
http://www.google.de/search?q=minimax&ie=UTF-8&oe=UTF-8
letzter Eintrag auf der Seite http://de.wikipedia.org/wiki/Minimax-Algorithmus.
Ich meinte zwar die kaufmännische Variante (z.B. irgendwo hier http://www.sam.sdu.dk/parn/parn/allpap1294), aber
das spielt keine wesentliche Rolle ist prinzipiell das Gleiche.

Was abstellen?

1. Schlampig zu arbeiten
  2. nicht genau zu wissen was ich tue

Das mache ich mit Grundlagenforschung, indem ich mich stückweise auch an die Sourcen von PHP herantaste.

Damit weißt Du aber imer nochnicht, was Du da genau tust. Wenn Du nur die Rosinen aus dem Kuchen porkelst weißt Du nicht, ob Deine Entscheidung evt Seiteneffekte hat. Du weißt ja noch nicht einmal, ob die Lösung der PHP-Entwickler geschwindigkeitsoptimal ist. Oder schaust Du jedesmal nach, was der Compiler aus dem C-Code an Maschinencode gezaubert hat? C erlaubt auch Inline-Assembler und das führt auch mich hin und wieder in Versuchung. Aber ich habe gelernt _vorher_ nachzuschauen, was der Compiler da selber optimiert. Das reicht in 99,9% der Fälle und für das restliche Promille ist der Aufwand einfach viel zu hoch. Ob Du den jetzt vorher betreibst oder jedesmal, also in Raten, spielt keine Rolle, kostet alles am Ende das Gleiche.
Dein Vorgehen ist einfach nicht ökonomisch.

Aber ich kann Dich natürlich auch verstehen: es macht Spaß einer Sache auf den Grund zu gehen. Und es macht auch Spaß, das dadurch erworbene Wissen in die Tat umsetzen zu können. Das rüttelt aber in keinster Weise an der Tatsache: es ist hier nicht nötig, denn Du kannst Dein Wissen nicht wirklich anwenden, das sieht nur von außen so aus.
Das Wissen über die Struktur des Quellcodes von PHP könntest Du nur gewinnbringend anlegen, wenn Du selber darin Änderungen ausführen willst/mußt, eine ähnliche Sprache schreiben willst oder z.B. auch nach Sicherheitsmängeln suchst. Danach zu schauen welche Funktion schneller ist, ist hingegen eine müßige Übung.

so short

Christoph Zurnieden