Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?

[Keks]

Ich bin gerade dabei, ein Projekt etwas zu entschlacken. Dabei wollte ich über den JCL Project Analyzer sehen, was am meisten Größe beansprucht und war über den ersten Eintrag in der Auflistung doch sehr verwundert:
http://www.delphipraxis.net/attachme...7&d=1293415774

An ein paar Stellen kommt die Jedi Library tatsächlich zum Einsatz, aber dass die JclStrings Komponente am Ende 20% der Programmgröße ausmacht, kann ich nicht nachvollziehen.
Jetzt ist die Frage, ob das so normal ist (warum?) oder ob da was falsch sein könnte (was?).
Hat jemand eine Idee bzw. könnte das in seinen Projekten, wo die Jedis zum Einsatz kommen, mal gegenchecken.

Und falls jemand einen besseren Vorschlag als den JCL Project Analyzer hat, her damit! :)

[alzaimar]

Was bedeutet denn 'BSS' (im Gegensatz zu 'CODE') in der rechten Spalte?

[Poelser]

Zitat:

Zitat von alzaimar (Beitrag 1070559)

Was bedeutet denn 'BSS' (im Gegensatz zu 'CODE') in der rechten Spalte?

Block Storage Segment. Dort werden z.B. Konstanten gespeichert.

CU, der Poelser

[BlueStarHH]

Wo kann ich den JCL Project Analyzer herunterladen? Gibt es den als Standalone-Applikation, ohne dass ich mir die komplette JCL installieren muss? Kann jemand evtl. hier die EXE uploaden? Danke!

[alzaimar]

Zitat:

Zitat von Poelser (Beitrag 1070561)

Zitat:

Zitat von alzaimar (Beitrag 1070559)

Was bedeutet denn 'BSS' (im Gegensatz zu 'CODE') in der rechten Spalte?

Block Storage Segment. Dort werden z.B. Konstanten gespeichert.

Danke.
Sieht dann wohl so aus, als ob die JclStrings 500kb an Daten / Konstanten definiert, z.B. Charmaps usw. 500k sind aber wirklich ziemlich happig.

[himitsu]

Die neueren Delphis (2009+) haben auch nochmal einige Charmaps und Dergleichen an Board ... also insgesamt fällt das dann nicht mehr so auf.

[Dezipaitor]

Sollte das nicht alles ausfallen, wenn optimiert wird?

[Keks]

Zitat:

Zitat von BlueStarHH (Beitrag 1070563)

Wo kann ich den JCL Project Analyzer herunterladen? Gibt es den als Standalone-Applikation, ohne dass ich mir die komplette JCL installieren muss? Kann jemand evtl. hier die EXE uploaden? Danke!

Ich habe JCL+JVCL installiert. Dann taucht der Menüpunkt "Project > Analyse Project" auf. Das Projekt wird dann beim Kompilieren analysiert. Ich glaube, das gibt es nicht als Standalone.

Zitat:

Zitat von alzaimar (Beitrag 1070566)

Sieht dann wohl so aus, als ob die JclStrings 500kb an Daten / Konstanten definiert, z.B. Charmaps usw. 500k sind aber wirklich ziemlich happig.

Also wenn der Eintrag zu der JclStrings.pas gehört, dann sind da eigentlich kaum Konstanten drin, sondern mehr String-bezogene Funktionen (StrSearch, StrPrefixIndex, usw.)

Zitat:

Zitat von himitsu (Beitrag 1070567)

Die neueren Delphis (2009+) haben auch nochmal einige Charmaps und Dergleichen an Board ... also insgesamt fällt das dann nicht mehr so auf.

Das war jetzt sogar der Grund, warum ich mit dem Optimieren angefangen habe. Ich habe Delphi 2006 durch XE ersetzt und bin da jetzt am Optimieren. Immerhin ist der erste Schock nach komplettem Entfernen von RTTI wieder überwunden. ;)

Zitat:

Zitat von Dezipaitor (Beitrag 1070595)

Sollte das nicht alles ausfallen, wenn optimiert wird?

Wäre schön. Auf jeden Fall ist im Projekt bei den Optionen "Optimization" aktiviert. Was anderes fällt mir da jetzt nicht ein. Generell handelt es sich um eine frische XE Installation mit den entsprechenden Komponenten als Standardinstallation.

[Keks]

Keiner eine Idee, wie man die Sache noch angehen könnte?
Und hat meine Beobachtung mal jemand gegengecheckt?

[jbg]

Am 5.10.2010 wurden bei der JclStrings.pas Unit IFDEFs eingebaut, die ab Delphi 2009 nicht mehr eigene Char-Maps aufbauen, sondern auf die von der Characters.pas Unit bereit gestellte Tabelle zugreifen. Dadurch entfallen die 500 KB im BSS Segment.

Bugreport:
http://issuetracker.delphi-jedi.org/view.php?id=5333

Die Änderung hat es aber nicht in die aktuelle Release Version JCL 2.2 Build 3886 geschafft. Im Daily Build ist die Änderung aber enthalten.

[Keks]

Alles klar, dann werde ich mal aktualisieren und danach nochmal Rückmeldung geben.
Vielen Dank für die Info!

[Keks]

Vielen Dank, hat geklappt! :thumb:

[Keks]

Nun steh ich doch tatsächlich ziemlich genau ein Jahr später erneut vor dem gleichen Problem. :(

Ich habe auf einem neuen Rechner meine Entwicklungsumgebung mit Delphi XE erneut aufgesetzt und alle Komponenten eingerichtet, darunter auch JCL+JVCL. Ich habe von beiden die aktuellen Daily-Builds genommen, da sich die JCL-Version aus dem aktuellen Stable JVCL-Paket nicht installieren ließ (irgendein Problem mit JclOtaUtils). Die beiden Daily-Builds wurden hingegen problemlos installiert.

Nach dem Kompilieren der Anwendung Stirnrunzeln: die exe ist ein gutes Stück größer als zuvor. Ein Blick in die Projekt-Analyse zeigt erneut das gleiche Bild wie vor einem Jahr: die JclStrings (BSS) belegt gut 500kB im Projekt. :(

Damals löste sich das Problem durch die Installation eines Daily Builds. Diesmal geht's leider nicht aktueller (JCL 2.4.0.4319). Ist in der Zwischenzeit bei JCL wieder was schiefgelaufen? Oder gibt es eine neue Lösung?

[jbg]

Schau mal in deine JclStrings.pas, ob dort "UNICODE_RTL_DATABASE" vorkommt. Wenn das fehlt, dann stimmt was mit dem Daily Build nicht (oder es werden keine neueren mehr erzeugt)


Du kannst das auch in einem eigenen Programm Testen:

Delphi-Quellcode:

program Test;
{$I jcl.inc}
begin
  {$IFNDEF UNICODE_RTL_DATABASE}
  'Da stimmt was nicht wenn das hier nicht Delphi XE ist'
  {$ENDIF}
end.

[Keks]

UNICODE_RTL_DATABASE kommt dort sogar recht häufig vor. 61 Mal um genau zu sein. Ich hab die Datei hier mal angehängt, vielleicht siehst Du da ja eher was.

Allerdings frage ich mich, wo UNICODE_RTL_DATABASE überhaupt definiert wird.
In der jcl.inc steht:

Delphi-Quellcode:

{$IFNDEF HAS_UNIT_CHARACTER}
  {$UNDEF UNICODE_RTL_DATABASE}
{$ENDIF ~HAS_UNIT_CHARACTER}

(wozu das "~"?)

Habe in meiner Anwendung mal getestet und es ist weder UNICODE_RTL_DATABASE noch HAS_UNIT_CHARACTER definiert. Und nu? :|

[USchuster]

Zitat:

Zitat von Keks (Beitrag 1143633)

UNICODE_RTL_DATABASE kommt dort sogar recht häufig vor. 61 Mal um genau zu sein. Ich hab die Datei hier mal angehängt, vielleicht siehst Du da ja eher was.

Allerdings frage ich mich, wo UNICODE_RTL_DATABASE überhaupt definiert wird.
In der jcl.inc steht:

Delphi-Quellcode:

{$IFNDEF HAS_UNIT_CHARACTER}
  {$UNDEF UNICODE_RTL_DATABASE}
{$ENDIF ~HAS_UNIT_CHARACTER}

(wozu das "~"?)

~ steht bei uns in diesem Fall dafür das dieses ENDIF einen Block beendet wo HAS_UNIT_CHARACTER nicht definiert ist (für den Compiler hat das keinerlei Bedeutung)

Zitat:

Zitat von Keks (Beitrag 1143633)

Habe in meiner Anwendung mal getestet und es ist weder UNICODE_RTL_DATABASE noch HAS_UNIT_CHARACTER definiert. Und nu? :|

HAS_UNIT_CHARACTER wird durch jedi.inc definiert und UNICODE_RTL_DATABASE durch jcldxx.inc (siehe jcl.inc; jcld15.inc für XE und jcld16win32.inc für XE2 Win32).

Für folgendes Programm sehe ich mit XE2 den folgenden Output, wenn ich UNICODE_RTL_DATABASE in jcld16win32.inc aktiviere. Vielleicht liegen bei Dir irgendwo veraltete Includes rum die Dein Programm verwendet.

Code:

RTLVersion: 23.0
HAS_UNIT_CHARACTER
UNICODE_RTL_DATABASE

Delphi-Quellcode:

program Project31;

{$APPTYPE CONSOLE}

{$I jcl.inc}

begin
  WriteLn('RTLVersion: ', RTLVersion:2:1);
  {$IFDEF HAS_UNIT_CHARACTER}
  WriteLn('HAS_UNIT_CHARACTER');
  {$ENDIF HAS_UNIT_CHARACTER}
  {$IFDEF UNICODE_RTL_DATABASE}
  WriteLn('UNICODE_RTL_DATABASE');
  {$ENDIF UNICODE_RTL_DATABASE}
  ReadLn;
end.

[TKC]

Hallo,
ich habe im Installer der JCL unter Conditional Defines -> Unicode Options
das Häkchen bei Prefer RTL Database gesetzt und dann installiert.
Dann passt es auch mit der Größe.

[Keks]

Zitat:

Zitat von TKC (Beitrag 1143732)

Hallo,
ich habe im Installer der JCL unter Conditional Defines -> Unicode Options
das Häkchen bei Prefer RTL Database gesetzt und dann installiert.
Dann passt es auch mit der Größe.

Der Wahnsinn! Genau das war's. Wow, vielen Dank!!

Jetzt frage ich mich dann doch, warum diese Option scheinbar geändert wurde, denn damals hatte ich das nicht manuell eingestellt.
Und zudem: Wozu ist sie überhaupt gut? Der einzige für mich sichtbare Unterschied ist die Dateigröße.

[Bernhard Geyer]

Zitat:

Zitat von Keks (Beitrag 1143739)

Und zudem: Wozu ist sie überhaupt gut? Der einzige für mich sichtbare Unterschied ist die Dateigröße.

Einmal nimmst du bei UpperCase & Co-Funktionalität die Implementierung der RTL und einmal aus der JCL.
Und bei beiden (darauf würde ich wetten) gibt es mindestens bei 2-3 Zeichen unterschiede gibt (so wie .NET, Java, Win32 und ElPack hier jeweils bei ein paar Zeichen eigene Interpretation der Unicode-Standards haben).