Unterschiedliche Größen des Kompilats FPC 3.2.2 vs. 3.2.3

[greye]

Hallo zusammen,

mir ist aufgefallen, daß bei gleichem Quellcode und gleichen Build-Einstellungen die beiden unten aufgeführten Kombinationen unterschiedlich große Ergenisse liefern.

Bei einem Testprojekt und
Lazarus 3.9 (rev lazarus_3_8-16-gf1feaaf4e0) FPC 3.2.2 x86_64-linux-gtk2
sind es 6341792 Byte.

Bei
Lazarus 4.0RC2 (rev lazarus_4_0RC2-165-gdc81b2e397) FPC 3.2.3 x86_64-linux-gtk2
sind es 6459664 Byte.

Nicht daß es so extrem wichtig wäre, aber rein aus Interesse würde ich schon gerne wissen wo der Unterschied von ~115kB herkommt. Vielleicht kann mich jemand erleuchten …

Danke,
42m

[af0815]

Du verwendest unterschiedliche Versionen vom FPC und auch von Lazarus. Somit sind die FCL und die LCL vom Umfang her unterschiedlich. Auch können sich die Abhängigkeiten der Units geändert haben, alles so Kleinigkeiten, die die Codegröße ändern können, egal welche Richtung.

[greye]

Du verwendest unterschiedliche Versionen vom FPC und auch von Lazarus. Somit sind die FCL und die LCL vom Umfang her unterschiedlich. Auch können sich die Abhängigkeiten der Units geändert haben, alles so Kleinigkeiten, die die Codegröße ändern können, egal welche Richtung.

Danke, sowas habe ich mir fast schon gedacht. Habe gerade Zeit - neben der Brennblase sitzen und warten, bis der Schnaps läuft ist zäh, wenn man sich nicht anderweitig beschäftigt . Von daher versuche ich vielleicht mal, die Kompilate auseinander zu nehmen und zu schauen, ob ich da was erkennen kann. Glaube ich zwar nicht, aber so als Übung … Schaden kann es jedenfalls nicht und verstehend ins Programm schauen zu können schadet sicher nie, wenn ich programmieren will

42m

[af0815]

Interessanter sind die Auswirkungen der Optimierungsstufen falls du dir was nebenbei ansehen willst.

[greye]

Interessanter sind die Auswirkungen der Optimierungsstufen falls du dir was nebenbei ansehen willst.

Über die bin ich schon gestolpert, als ich mich gewundert habe, warum im Release Build (-O3) die mühsam gezimmerte Schleife, die einfach nur ein paar Millionen mal Blödsinn berechnen sollte, "wegoptimiert" war. "Schuld" war DFA, das richtigerweise der Meinung war, daß eine Schleife, deren Ergebnis nirgendwo verwendet wird, auch weg kann.
Hat ein bisschen gedauert, bis ich drauf kam …
viewtopic.php?p=147556#p147556

42m

[Mathias]

Über die bin ich schon gestolpert, als ich mich gewundert habe, warum im Release Build (-O3) die mühsam gezimmerte Schleife, die einfach nur ein paar Millionen mal Blödsinn berechnen sollte, "wegoptimiert" war. "Schuld" war DFA, das richtigerweise der Meinung war, daß eine Schleife, deren Ergebnis nirgendwo verwendet wird, auch weg kann.

Solche Schleifen sind sowiesd schlecht, während der TP Zeit habe ich dies auch nicht realisiert, das die PCs immer schneller werden und damit auch die Schleifen kürzer.
Daher ist es besser man nimmt irgend ein Delay vom System.

[greye]

Solche Schleifen sind sowiesd schlecht, während der TP Zeit habe ich dies auch nicht realisiert, das die PCs immer schneller werden und damit auch die Schleifen kürzer.
Daher ist es besser man nimmt irgend ein Delay vom System.

Ja, aber nein, aber ja, aber nein, aber … <vicky_pollard />

Würde ich normalerweise auch so machen, wenn ich eine bestimmte Zeit "vertrödeln" will, aber mir ging es in dem Fall gerade darum, die Unterschiede verschiedener Arten einer Berechnung zu testen. Da war es dann seltsam, daß alle Varianten in nicht mal einem Tick fertig waren

Aber ich habe was dabei gelernt, das war es dann auf jeden Fall wert.

42m