Schnürsenkel-Code
Habe ich ehrlich noch nie gehört; kann mir aber gut vorstellen, was ihr meint, jedoch
googlet mal danach! Vermutlich wird dieser Forumspost der erste Eintrag, der
nicht mit diesen Etiketten zu tun hat …
Thema: Übersicht ist gut, Struktur ist essentiell, Abstrahieren von Vorteil – und rechnerisch dürfte ein Include keinen spürbaren Geschwindigkeitsverlust beim Kompilieren verursachen. Ein Include ist ja unterm Strich nichts anderes als ein 1:1-Einfügen externen Quellcodes an genau der Stelle in der zu kompilierenden Datei, an der diese Codezeilen normalerweise ausgeschrieben würden. Voraussetzungen für die beste Performance: (1) die Include-Datei befindet sich im selben Ordner wie die aufrufende Datei (höchstens in einem Unterordner); deswegen: (2) die Include-Datei liegt
nicht in einem entfernten Pfad/auf einer anderen Partition (Wahrscheinlichkeit hoher Fragmentierung beachten) oder schlimmstenfalls auf einem entfernten Laufwerk/Speichermedium!
Die Schreib-/Lesezugriffszeiten moderner Laufwerke dürften diesen Prozess wohl kaum negativ beeinflussen.
Eine Ausnahme gibt es aber: Speicherkarten und speicherkartenähnliche Medien – wie z.B. USB-Sticks, Flashcards, Memorysticks etc. –, deren Schreib-/Leserate bauartbedingt asynchron ist (schnell lesen, langsam schreiben; jeder kennt das von (A)DSL/(Consumer) Cable Internet)! Mit diesen Medien sollte man nicht dauerhaft eingebunden arbeiten. Ja – viele sagen: Klar, das geht schon und funktioniert auch. Funktionieren tut es tatsächlich, aber niemand darf sich dann über schlechte Performance wundern. Ich möchte damit nur klarstellen, dass nicht allein die Speichergröße das Nadelöhr ist, sondern die Datentransferrate (inkl. internem Bus) als Flaschenhals entlarvt werden muss. Dem
Arbeitsspeicher ist es an sich egal, woher er wieviel Daten bekommt; Hauptsache, er bekommt sie, und füllt sich selbst, bis er gesättigt ist. Daran ändert ausgelagerter oder Inlinecode gar nichts. Prozessor wartet auf RAM, und RAM wartet auf die anderen M’s – vorher wird nicht gerechnet
mit einem guten editor, der abschnitte - mit { } ( ) < > und << >> zu erkennen - stufenweise zusammen- und wieder auseinanderfalten kann (etwa notepad++) lässt sich aber ein ähnlicher effekt erreichen und der schnürsenkelcode wird gemildert!
Jawohl, da kommen uns die Anwendungsentwickler toll entgegen! Es ändert zwar nichts an der internen Codezeilenanzahl, aber man muss schon selbst noch den Überblick behalten. Man muss sich immer fragen: Lohnt sich jetzt schon ein Auslagern oder nicht? Zum Beispiel braucht man für ein zweiseitiges Chorstück eben
keine vier Includes (eins pro Stimme); für eine gemeinsame Ausgabe zweier Motetten hingegen schon (je ein Include pro Motette). Es ist zudem in Lily absolut vorteilhaft, da man aus einer zentralen Datei heraus mittels verschiedener \book- oder \score-Blöcke unterschiedliche Ausgaben produzieren kann.
Ein weiteres, riesengroßes Plus für die Includes ist die Auslagerungsmöglichkeit aller bisher benutzten und häufig wiederkehrenden Snippets: Vortragsbezeichnungen, selbstgebaute Dynamikangaben, knifflige Tweaks usw. Ich sammle all das systematisch in verschiedenen Dateien, die von vornherein in jede neue Partitur eingebunden werden. Und selbst wenn meine „Dateibibliothek“ für Vortragsbezeichnungen/Dynamik mittlerweile auf über 50 verschiedene Einträge angewachsen ist (Tendenz steigend), merke ich keine Geschwindigkeitsabnahme. Lily zieht sich nur das heraus, was es benötigt. Wenn ich z.B. eine einzige Seite Chornoten schreibe und darin nur eine einzige Angabe aus meiner „Bibliothek“ brauche (bspw.
poco a poco cresc.), ist Lily genauso schnell, obwohl es zunächst die komplette Datei zusätzlich einlesen muss.
Fazit: Ich habe die Laufzeiten bisher nie gestoppt, hatte aber auch nie Grund dazu. Alles läuft wie am Schnür(senkel)chen
Beste Grüße, Robert
