Delphi-PRAXiS
Seite 6 von 15   « Erste     456 78     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Klatsch und Tratsch (https://www.delphipraxis.net/34-klatsch-und-tratsch/)
-   -   Find out why after 22 years more developers than ever are choosing Delphi (https://www.delphipraxis.net/193185-find-out-why-after-22-years-more-developers-than-ever-choosing-delphi.html)

jaenicke 4. Jul 2017 03:48

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Die Diskussion sollte vielleicht besser abgetrennt werden...

Zitat:

Zitat von SneakyBagels (Beitrag 1375884)
Zitat:

Bei Ressourcen weiß der Compiler es nicht.
Da müsste Emba mal beim {$R} einbauen, dass man da ein "lass weg, wenn nicht direkt referenziert"-Flag angeben kann, aber es gibt eh keine direkten Ressouren-Referenzierungen.
Aber bräuchte man dafür dann nicht schon fast einen 2-Wege-Compiler so wie bei C++?

Nein, eine Lösung für P=NP. Denn der Compiler müsste auch den kompletten Quelltext inkl. einkompilierter Objectfiles usw. durchgehen um zu schauen, ob da irgendwo die Ressource verwendet wird...
Beispiel:
Der Ressourcenname wird dynamisch generiert und in eine Variable gepackt, die dann an TRessourceStream übergeben wird.
Wie soll der Compiler das erkennen?

Zitat:

Zitat von EWeiss (Beitrag 1375874)
Ein Compiler der einem aufzwingt dinge in sein Programm mit ein zu kompilieren was nicht nötig und NICHT verwendet wird der Taugt nichts.

Wenn du z.B. den verbesserten Speichermanager von Delphi 2006 und höher nicht verwendest, wäre ich gespannt auf den entsprechenden Quelltext.
Das sind übrigens alleine ca. 6000 Zeilen Code (getmem.inc).

Vermutlich sagst du jetzt, dass du den ja gar nicht verwenden willst? Weil deine Programme nicht schneller sein sollen, wenn dadurch die Exe größer wird? Da dürften aber 99,9% der Entwickler und Anwender anderer Meinung sein.

Zitat:

Zitat von EWeiss (Beitrag 1375874)
Zitat:

@TiGü Wenn du wirklich reine Non-VCL und Non-RTL Programme schreiben würdest, wäre die EXE in Turbo Pascal, Delphi 2, Delphi 7, Delphi 2010, Delphi Tokyo und so weiter annähernd gleich groß.
Quatsch mach's einfach mal dann siehst du das deine Behauptung für'n.. Ar.. ist.

Delphi 2 7 KiB, Delphi 7 13 KiB, Delphi 2006 17 KiB, Delphi XE 20 KiB, Delphi XE6 21 KiB, Delphi 10.1 Berlin und 10.2 Tokyo 44 KiB.
Der Sprung zwischen Delphi 7 und Delphi 2006 ist der aus dem Fastcode Projekt hervorgegangene deutlich schnellere Speichermanager.
Für den zweiten Sprung müsste ich erst suchen was da in der Exe neu drin ist.

Ohne VCL und RTL ist es jedenfalls nicht so, dass es ständig so große Steigerungen gibt, sondern es sind vor allem zwei (in Relation) große Sprünge.

EWeiss 4. Jul 2017 05:44

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Vermutlich sagst du jetzt, dass du den ja gar nicht verwenden willst? Weil deine Programme nicht schneller sein sollen, wenn dadurch die Exe größer wird? Da dürften aber 99,9% der Entwickler und Anwender anderer Meinung sein.
Es gibt nicht umsonst in C++ Möglichkeiten sein Kompilat zu Optimieren. ;)
Keine/Größe/Geschwindigkeit usw... Bin ich der einzige also das 1% das diese Möglichkeiten ausnutzt? Möchte ich bezweifeln.
Dabei sind aber die Optimierungen des Linker noch nicht mit eingeschlossen.

Die Frage ist was verstehst du unter schneller.
Die Start Geschwindigkeit eines Programms wird von Windows verwaltet oder warum glaubst du gibt es die Caches?
Zudem hängt es stark von der Art der Verwendung ab.
Wenn ich eine Liste von 10000 Einträgen mit einer TStringlist verwalte anstatt auf eine Datenbank auszuweichen dann ist man selbst schuld.

Zitat:

Delphi 2 7 KiB, Delphi 7 13 KiB, Delphi 2006 17 KiB, Delphi XE 20 KiB, Delphi XE6 21 KiB, Delphi 10.1 Berlin und 10.2 Tokyo 44 KiB.
Danke das du dir die Mühe gemacht hast.

Man sieht also das meine Behauptung nicht von der Hand zu weisen ist.
Eine Faktor von 3(D7 zu Tokyo) ist für mich persönlich inakzeptabel.
Mehr ist dazu nicht zu sagen.

gruss

jaenicke 4. Jul 2017 07:15

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Wenn du den alten deutlich langsameren Speichermanager usw. haben möchtest, weil du nicht möchtest, dass etwas Modernes und eben größeres in deiner Exe landet, dann bleibt dir in der Tat nur eine alte Delphiversion.

Langsam bedeutet bei jeder Speicheranforderung, z.B. wenn du einen String zuweist usw., ist es etwas langsamer. Natürlich nicht gleich sekundenweise, aber es läppert sich. Details, Vergleichstests usw. findest du beim Fastcode Projekt eventuell noch.

TiGü 4. Jul 2017 09:12

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von EWeiss (Beitrag 1375874)
Quatsch mach's einfach mal dann siehst du das deine Behauptung für'n.. Ar.. ist.
Oder damit du wenig Arbeit hast erstelle ein leeres DLL/Projekt und vergleiche die Unterschiede.

Leeres Konsolenprojekt, dieser Quelltext:

Delphi-Quellcode:
program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

begin

end.
Gebaut für 32 Bit, Release, gleiche Projektoptionen - Größe der Anwendung:

Delphi XE 1 (ja, das erste...das nach Delphi 2010): 109 KB (112.128 Bytes).
Delphi Tokyo 10.2: 44,0 KB (45.056 Bytes)

Hm, wie nun? :roll:
Sollten die doch ein bisschen Gehirnschmalz in den Compiler und Linker gesteckt haben im Laufe der Zeit?

EWeiss 4. Jul 2017 09:51

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Hm, wie nun?
Es zeigt sich mal wieder das dein Beitrag sich doch sehr von der Testvariante vom @jaenicke unterscheidet.
Papier ist geduldig.

Hm, wie nun? :roll:

Wie dem auch sei letztendlich ist ausschlaggebend wie meine Projekte mit Tokyo kompiliert werden und das ist schlichtweg nicht akzeptabel.
Da kann man auch nichts gut reden.
Aber jeder wie er möchte.

gruss

TiGü 4. Jul 2017 09:58

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von EWeiss (Beitrag 1375919)
Wie dem auch sei letztendlich ist ausschlaggebend wie meine Projekte mit Tokyo kompiliert werden und das ist schlichtweg nicht akzeptabel.
Da kann man auch nichts gut reden.
Aber jeder wie er möchte.

Jup...ich mein, wer kennt das nicht?
Da kompiliert man mit einer neuen Delphiversion seinen alten Quelltext und plötzlich werden aus 400 KB Kompilat rund 1200 KB.
Ruckzuck war die 500 GigaByte SSD voll und Windows startete nicht mehr.
Passiert mir auch...ständig...immerzu...nicht!

EWeiss 4. Jul 2017 10:00

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Kürzen wir das ab.. da es langsam lächerlich wird.
Du hast Recht und ich meinen Frieden.

gruss

Sherlock 4. Jul 2017 10:09

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Man sollte meinen Daniels humorige Ermahnung sollte reichen, offenbar nicht. Schade.

Sherlock

Towmuz 4. Jul 2017 10:10

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von EWeiss (Beitrag 1375921)
Kürzen wir das ab.. da es langsam lächerlich wird.
Du hast Recht und ich meinen Frieden.

gruss

Ihr seid nicht zufällig verheiratet? :>

EWeiss 4. Jul 2017 10:11

AW: Find out why after 22 years more developers than ever are choosing Delphi
 
Zitat:

Zitat von Sherlock (Beitrag 1375926)
Man sollte meinen Daniels humorige Ermahnung sollte reichen, offenbar nicht. Schade.

Sherlock

Ich habe damit abgeschlossen. Danke :)

gruss


Alle Zeitangaben in WEZ +1. Es ist jetzt 06:16 Uhr.
Seite 6 von 15   « Erste     456 78     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz