Kürzerer Code ist immer schneller?
 

Mir ist in den letzten Tagen eine These durch den Kopf geschwirrt. Ist kürzerer Code immer schneller?

Als Programmierer versucht man ja sein Programm so leistungsstark wie möglich zu entwerfen. Je mehr Zeilen Code man dann hat desto mehr muss auch abgearbeitet werden. Folglich braucht man bei mehr Zeilen Code länger. Aber ist das wirklich so?

Kennt ihr Beispiele oder könnte welche Konstruieren wo Code der länger ist schneller läuft? Und kommt mir jetzt nicht mit Funktionen. Es geht um das was abgearbeitet wird. Immer wenn ich eine Funktion aufrufe steht dahinter ja auch Code der abgearbeitet wird. Dieser würde dann immer beim Aufruf dazu gezählt werden.

Theoretisch brauchst du je mehr Code du hast, mehr Anweisungen, damit mehr CPU-Zyklen und damit mehr Zeit.

Praktisch kann es aber sein dass du einfach mehr Anweisungen brauchst um eine bessere Lösung für dein Probmen zu finden. Angenommen du willst (in C) Textdateien einlesen, außerdem nehmen wir an dass die Dateien ein paar GB groß sind. Wenn du so große Dateien einlesen willst ist es Sinnvoll, unter Linux, [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...] zu verwenden. Das machst du in C unter Linux mit madvise(). Wenn du jetzt also madvise() in dein Programm packst, hast du mehr Code, brauchst vermtl mehr CPU-Zyklen aber die Verarbeitung deiner Textdatei geht wesentlich schneller.

Also wenn man z.B. in Excel mit VBA Zellen vergleicht und dann bei irgendeiner erfüllten Bedingung etwas in eine bestimmte Zelle schreibt, kann das schon ziemlich lange dauern. Deshalb bietet es sich einfach an, zunächst zu überprüfen, ob der Zellinhalt bereits mit den zu schreibenden Daten übereinstimmt, um dann den Schreibvorgang zu überspringen. Das spart richtig Laufzeit...

VBA war wahrscheinlich jetzt nicht in deinem Sinne, aber prinzipiell stimmt's... Lese- und Schreibvorgänge durch zusätzlichen Code einsparen, ist daher aus meiner Sicht immer sinnvoll.

Die These ist ziemlich unsinnig.
Man kann ja 1000 Anweisungen in eine Methode packen. Ist die Ausführung deshalb schneller?

Des Weiteren habe ich noch nie erlebt, dass man versucht nach Performance zu programmieren. In erster Linie programmiert man nach SOLID, OOP- Paradigmen und entsprechenden Schichtmodellen.
Wartbarkeit ist wichtiger als reine Performance.

Ich habe EA einmal erlebt, dass jemand der Meinung war, dass Architekturhilfen und Frameworks (ORM, SOA, DI-Container usw) verzichtet hat, da die Projizierungen ja performancelastig sind...dabei rausgekommen ist reiner Müll, der nicht funktions fähig war.

Ich denke es ist ganz Stark abhängig davon in welchem Feld du bist worauf der Focus liegt ProgMaster. Wenn ich eine Determinanter einen 100.000 x 100.000 Matrix erechnen möchte, dann kommt es schon auf Performance an. Wenn du wie bei Google Millionen Suchergebnisse innerhalb von 0,001233 Sekunden ausgeben möchtest, auch dann kommt es auf Schnelligkeit an.

Das mit dem Kopieren ist aber ein gutes Beispiel. Es dauert länger dass man alles kopiert anstatt zu schauen ob es schon vorhanden ist und nur das zu Kopieren was man wirklich braucht. Wobei dass ja 2 von der Anwendung her verschiedene Dinge sind.

Aber jetzt so richtig die Komplett gleiche Anwendung nur anders programmieren? Es wird bestimmt Beispiele geben bei denen es Rekursion und Iteration geben kann. Vielleicht dann sogar dass das was mehr Codezeilen benötigt schneller ist. Wobei dass dann eher an der Änderung des Algorithmus liegen wird.

Odata, das ist so aber einfach ziemlicher Quatsch.

1. Jede moderne Programmiersprache wird kompiliert. Aus einer Zeile Code können mehr Anweisungen erfolgen als aus mehreren Hundert. Mach Dir mal Gedanken zu syntaktischem Zucker. Das allein reicht schon um deine These zu widerlegen.

2. Mehr CPU Anweisungen = mehr Ausführungsdauer...das würde schon mehr Sinn machen, ist aber auch nicht richtig. Wenn die Ausführung parallelisierbar ist, dann kommt es letztendlich auf eine gute Lastverteilung an. Und dann ist es auch wiederum die Wahl eines Algorithmus.

Wie Du siehst ist deine These sehr leicht zu widerlegen.
Des Weiteren wird auch Google Frameworks einsetzen (teilweise schreiben die diese ja selbst) die die Architektur verbesseren, aber die Anzahl der Anweisungen erhöht.

Kann man ein kurzes Wort schneller aussprechen als ein langes?

Vergleiche einfach mal Such und Sortier-Algorithmen an und du wirst feststellen dass kürzerer Code nicht schneller sein muss.

Diese These ist definitiv falsch.
Ganz "unter der Haube" kommt es darauf an, wieviele CPU-cycles ein Opcode zur Ausführung braucht.
Und es gibt nun mal Opcodes die z.B. 1 cycle brauchen (mov == Werte verschieben) und welche, die deutlich mehr brauchen (z.B. 4 für imul == (signed) Integer Multiplikation).

Ich könnte also schreiben:
4 LOC; 4 CPU-cylces

1 LOC; 4 CPU-cycles

Das Beste: die Anzahl der Cycles hängt auch noch komplett vom verwendeten Prozessormodell ab. ;-)

Langer Code = schneller ?
 

Es ist schon möglich, dass langer Code schneller ist als kurzer - Beispiel FOR-Schleifen

haben häufig einen ziemlichen Overhead an Code, wird dann z.B. noch ein Array mit der FOR-Variablen angesprochen

For i=1 to 10 Array[i]:= irgendwas ...

ist es i.d.R. deutlich schneller Array[1]:= ... Array[10]:= zu schreiben

zumal viele Compiler Array[1] direkt mit der Speicheradresse auflösen und nicht in jeder
FOR Schleife die Speicheradresse berechnen.

Andererseits kann auch sehr viel von der Zielmaschine abhängen, hat der Prozessor (Pentium etc.) die komplette Schleife im Cache oder muss er mühsam jeden Befehl aus dem Speicher laden (8-bit 8051).

Es gibt wenige Anwendungsfälle, wo kürzerer Code vielleicht die lesbarkeit verbessert aber nicht zwangsläufig die Performance. Oftmals wird auch auf ein Framework zurückgegriffen aber selbst hierbei heißt es nicht gleich = wenig eigener Code = mehr Performance.

Zu allererst sollte der Code sauber sein. Strukturen und Methoden einer OOP-Angewandten Sprache sollten eingehalten werden und der Code sollte stabil laufen.
Danach kann man sich Gedanken über die Performance machen.

Es gibt auch recht wenige Beispiele wo RTC zur Anwendung kommt.

Und Selbst bei Suchmaschinen wie Google kommen bei Berechnungen a) mehrere vernetzte System und b) eigene Frameworks zum Einsatz.

Es kommt darauf an was für Funktionen man nutzt und auf die CPU.

Ich beziehe mich jetzt auf SPS Programme dort dauert z.b. auf einer der aktuellsten CPU's eine Bit Operation 1ns und eine Wortoperation (16 Bit) im schnitt 3ns (hängt auch davon ab was für eine Operation gibt genaue Listen dafür)

Ist jetzt nur eine Beispielrechnung also die Werte stimmen nicht ganz.

Vergleiche ich 2 Worte im und nach dem Schema
Und Bit 1
Und Bit 2
Ist Bit 3

Benötige ich 3 Bit Operationen für 1 Bit also x16 ist 48 Operationen sind 48ns

Mache ich das Ganze als Wort
Und Wort1
Und Wort2
Ist Wort 3

Benötige ich 3 Wortoperationen und bin bei 9ns.

Es kommt darauf an wie Maschinennah man Programmiert, wenn eine Programmiersprache Kompiliert wird kann es sich wieder ganz anders verhalten.
Aber am Ende kommt es immer darauf an was für Operationen habe ich und wie schnell kann meine CPU diese bearbeiten.

Am schnellsten wäre der Code in 0 und 1.Der wäre sehr lang. Es kommt eher darauf an was mit dem Code passiert, welche Sprachen genutzt werden u s w. Daher ist die Aussage kurz = besser für mich nicht richtig.
Gruß

Kanu willste Haare spalten?
Es geht darum eine gestellte Frage zu beantworten. Soviel zum Inhalt.

Klar Windows, Linux und Co arbeiten natürlich alles gleich schnell ab ;-) .... türlich



[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]

Schönen Tag noch.

Betrachte die Frage. Es geht darum ob kürzerer Code IMMER schneller ist. Diskutier doch nicht über die Effizenz von Programmsprachen?!? Es geht doch nicht darum ob ein Prozessor Langsamer arbeitet. Tust du die selbe Sache auf unterschiedliche Weise, brauchst du unterschiedlich Zeit. Es lässt sich aber nicht aus der Länge eines Codes ableiten, wie Effizent oder schnell der Code seine Aufgabe verrichtet.

@wachtel: Dass Maschinencode (!= Assembler!) "am schnellsten", dabei jedoch "am längsten" ist, ist zwar formal richtig, aber die Frage betreffend reiner Blödsinn. Wenn, dann müsstest du zwei Stück Code in Maschinencode vergleichen, die exakt das selbe machen, aber eine unterschiedliche Länge haben.

Sinn des Compilers ist es ja u.a., neben der Erzeugung von Maschinencode auch die Optimierung von Code. Es kann also durchaus sein, dass zwei unterschiedlich lange Code Stücke am Ende genauso schnell sind, da sie vom Compiler optimiert und kompiliert werden.

Ich glaube die ursprüngliche These kann mit Ja beantwortet werden, solange kein Gegenbeispiel gefunden ist (was schwierig sein dürfte, aber ich denke keinesfalls unmöglich).

Die Gegenbeispiele sind doch schon da gewesen: Sortieralgorythmen. Bubblesort lässt sich in wenigen Zeilen Code erstellen, ist aber verdammt langsam. Andere Verfahren sind zwar vom Code her länger, werden aber weit schneller abgearbeitet, da sie effizienter sind.

Oh, übersehen.