F2046 Zu wenig Arbeitsspeicher (Delphi)

[Sel2012]

Meine 150 MB-App machte bisher beim Compilieren etc. keine Probleme. Ich nutze XE5.
Jetzt habe ich eine Varante auf 90 MB abgespeckt. Ohne Images klappt's auch.
Nun habe ich ca. 200 jpgs (je ca. 30 kB) mit MultiResBitmaps auf 5 Images verteilt - klappt auch noch.
Aber bei 3 zusätzlichen Bildchen kommt beim schlichten Versuch zu speichern die Fehlermeldung "Zu wenig Arbeitsspeicher". Auch beim Compilierungsversuch kommt die Meldung (s. Titel).
Der Taskmanager gibt keinen Hinweis auf Überlastung des Speichers (. Anhang). Ich glaube, die Hilfe zu MSBuild und DP und Google durchforstet zu haben. Den Rat aus XE8 "Wählen Sie Projekt > Optionen > Delphi-Compiler, und aktivieren Sie die Eigenschaft "MSBuild extern für die Compilierung verwenden"" kann ich in XE5 nicht befolgen, da es die Einstellmöglichkeit nicht gibt.
Hat jemand damit Erfahrung? Probleme scheint es ja mehrfach zu geben.

[Bernhard Geyer]

1500 MB App?
Also in unserer App stecken >> 10 Mannjahre Entwicklung und 2 Mio. Quellcodezeilen aber wir bekommen keine 90 geschweige denn 150 MB hin.
Ich denke du machst da einiges Falsch (zusätzlich zu den Speicherlücken der IDE).

Müssen es den JPEGs sein? Reichen nicht PNGs (in einer ImageListe) auch?
Erstellst du alle Formulare beim Programmstart? Wieso?

[mensch72]

Soviel JPG Bilder als Resourcen... JPEG wird bei XE5 dann intern oft ausgepackt gespeichert bzw. zumindest entpackt verarbeitet.

Simple Lösung:
-> nimm einfach eine externe "Bilddatenbank" im einfachsten Fall mit einem numerischem Indexfeld und einem BlobFeld fürs Bild

[Sel2012]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320835)

Müssen es den JPEGs sein? Reichen nicht PNGs (in einer ImageListe) auch?
Erstellst du alle Formulare beim Programmstart? Wieso?

Hallo Bernhard,

ohne die Bilder werden 2000 Zeilen aus Memos einzeln nacheinander gelesen und jeder Zeile wird eine kurze mp3-Datei zugeodnet. Nebenbei wird jede Textzeile noch analysiert und farblich bearbeitet - das war's schon. Ich kenne keine Methode, die mp3s zu verkleinern. Das scheint sich aufzusummieren.
Die Bildquellen werden über MultiResBitmaps direkt ins Programm übernommen und nicht separat (zusätzlich) gelagert. Auch dafür kenne ich keine Alternative.
Wie kommst du auf 1500 MB? Die .apk ist auch "nur" 49 MB groß. Keine Ahnung, wie man das schrumpfen kann. Also im Grunde liefern
Memos resourceschonend Text in ein relativ kleines Programm und mp3 wird "beigestellt".
Prinzipiell meine ich, dass XE5 und MSBuild mit 200 MB nicht überfordert sein dürfte, da das Programm nicht komplex verschachtelt ist, sondern fast linear arbeitet.
Aber natürlich greife ich gern Alternativen auf.

Vielen Dank erst einmal
Udo

[Bernhard Geyer]

APK? Also FMX - Das hättest du gleich am Anfang angeben sollen.
Bei FMX gibts noch ein paar andere Faktoren als bei einem VCL-Projekt.

[Mavarik]

Erstmal alles in eine Resource...

Die Resource natürlich erstmal Packen...

Memo als "Textspeicher"... :shock:

[mensch72]

eigentlich "riecht" hier alles nach einer kleinen Datenbank(z.B. SQlite), aus welcher im OwnerDrawRow einer "Anzeigeliste" alles live für eine Zeile zusammengesucht, Regel basiert bearbeitet und ausgegeben/"gemalt" wird.

Farbiger Text, Bildchen, MP3s und was auch immer werden so völlig ohne "alles erstmal in den Speicher laden" fix OnDemand sauber gelöst.

[Sir Rufo]

Bei der Menge an Ressourcen würde ich mit Stellvertreter-Objekten und einem Cache arbeiten.

Die Stellvertreter laden bei Bedarf die Daten aus dem Cache oder vom Datenträger (und befördern die Daten in den Cache). Dadurch sind die scheinbar dauerhaft verfügbar, belasten den Speicher aber nur wenig, bzw. ich kann die Auslastung selber steuern.

[Sel2012]

Erst einmal vielen Dank für die interessanten Vorschläge.
Leider bin ich zu unbedarft, um sie umzusetzen, da ich keine Erfahrungen allein mit den Begriffen habe.

Ich habe versucht, mit der XE8-Anleitung weiter zu kommen:
http://docwiki.embarcadero.com/RADSt...r_%28Delphi%29

"F2046 Zu wenig Arbeitsspeicher (Delphi)

Dieser Fehler wird ausgegeben, wenn für den integrierten RAD Studio-Compiler zu wenig Arbeitsspeicher vorhanden ist.

Dieser seltene Fehler könnte auftreten, wenn Sie eine extrem große Projektgruppe mit Anwendungen und Bibliotheken erzeugen.

Führen Sie zur Lösung dieses Problems einen der folgenden Schritte aus:

Vergewissern Sie sich, dass die Auslagerungsdatei groß genug ist und ausreichend freier Festplattenspeicher zur Verfügung steht. Siehe Ändern der Größe des virtuellen Arbeitsspeichers.:
http://windows.microsoft.com/en-us/w...#1TC=windows-7

Konfigurieren Sie Ihre Projektgruppe so, dass ein Erzeugen außerhalb der IDE möglich ist: Wählen Sie Projekt > Optionen > Delphi-Compiler, und aktivieren Sie die Eigenschaft "MSBuild extern für die Compilierung verwenden".
Erzeugen Sie Ihre Projektgruppe in der Befehlszeile.
Gestalten Sie die Anwendungen und Bibliotheken in Ihrer Projektgruppe so, dass sie überwiegend Delphi-Packages verwenden. Mit Delphi-Packages steht für die IDE ausreichender Arbeitsspeicher zur Verfügung."

Ich habe also den virtuellen Arbeitsspeicher auf 6000 MB erweitert und bei weiteren 120 Bildchen (ab letzem Mecker "zu wenig Arbeitsspeicher") bisher keinen beleidigten Kommentar des Programms bekommen.

Ich probiere mal weiter....

Für andere Komprimierungsstrategien mit FMX bin ich zu dumm :oops:

[Mavarik]

Dann google doch mal ZlibEx, Streampacker und Daten als Resource einbinden.

[Bernhard Geyer]

Zitat:

Zitat von Sel2012 (Beitrag 1320857)

Ich habe also den virtuellen Arbeitsspeicher auf 6000 MB erweitert ...

Seit gefühlt 20 Jahren lässt man die größer der Auslagerungsdatei automatisch von Windows bestimmen. Nur in Spezialfällen stellt man selbst einen Wert ein.
Wenn du dies auf deiner Checkliste für Windowsinstallation hast, lösche diesen Eintrag. Das war noch unter Win3.1 sinvoll, aber nicht mehr bei in 2015 verwendeten Windows-Versionen.

[HolgerX]

Zitat:

Zitat von Sel2012 (Beitrag 1320838)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320835)

Müssen es den JPEGs sein? Reichen nicht PNGs (in einer ImageListe) auch?
Erstellst du alle Formulare beim Programmstart? Wieso?

Hallo Bernhard,

ohne die Bilder werden 2000 Zeilen aus Memos einzeln nacheinander gelesen und jeder Zeile wird eine kurze mp3-Datei zugeodnet. Nebenbei wird jede Textzeile noch analysiert und farblich bearbeitet - das war's schon. Ich kenne keine Methode, die mp3s zu verkleinern. Das scheint sich aufzusummieren.
Die Bildquellen werden über MultiResBitmaps direkt ins Programm übernommen und nicht separat (zusätzlich) gelagert. Auch dafür kenne ich keine Alternative.
Wie kommst du auf 1500 MB? Die .apk ist auch "nur" 49 MB groß. Keine Ahnung, wie man das schrumpfen kann. Also im Grunde liefern
Memos resourceschonend Text in ein relativ kleines Programm und mp3 wird "beigestellt".
Prinzipiell meine ich, dass XE5 und MSBuild mit 200 MB nicht überfordert sein dürfte, da das Programm nicht komplex verschachtelt ist, sondern fast linear arbeitet.
Aber natürlich greife ich gern Alternativen auf.

Vielen Dank erst einmal
Udo

Puh...
1.) Memos sind Komponenten für die Anzeige von Text 'zur Laufzeit', gerade bei größeren Texten und nicht dafür vorgesehen große Mengen von Text bei Compilierung zu halten!
Und anstelle dann mehrere Memos zu platzieren, solltes Du den ganzen Text in eine separate Textdatei packen und diese einfach mit LoadFromFile laden. Dadurch kannst Du dann diesen Text auch leichter korrigieren oder gar Multilingual machen.
2.) Auch deine Bilder kannst Du in ein separates File nacheinander gereiht packen und dann (ebenfalls zur Laufzeit) öffnen.
Hier würde ein FileStream genügen, bei dem Du die Bilder nacheinander einließt und z.B. in eine ImageList lädst. Auch dadurch hast Du die Möglichkeit, ohne Neukompilierung Bilder zu ersetzen.
3.) Das gleiche wie bei den Bildern kannst Du auch mit deinen MP3s machen.

Somit besteht dein Projekt dann aus einer (kleinen) Exe und 3 weiteren Dateien.

Um noch mehr Platz zu sparen, kannst Du Dir eine Routine als Ersatz für z.B. SaveToFile/LoadFromFile erstellen, welche vorher beim speichern deiner Daten diese zunächst mit zLib komprimiert und beim Laden entpackt.
Die Zip Funktionen, welche bei Delphi mitgeliefert wird, sollte dafür problemlos ausreichen.

Zusätzlich kann dann niemand (Kunde) an den Daten leicht was Ändern, da er beim öffnen der z.B. Texte-Datei nur Zeichensalat (gezippte Texte) vor sich hat.

[Dalai]

[OT]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320865)

Seit gefühlt 20 Jahren lässt man die größer der Auslagerungsdatei automatisch von Windows bestimmen. Nur in Spezialfällen stellt man selbst einen Wert ein.

Dem kann ich nicht zustimmen. Es ist immer zu bevorzugen, der Auslagerungsdatei eine feste Größe zu geben. Dadurch gibt es - wenn eh schon ausgelagert werden muss - keine Fragmentierung durch die nicht-dynamische Größe, was die Zugriffsgeschwindigkeit nochmals drastisch reduzieren würde. Außerdem legt Windows immer eine Mindestgröße von vom 1,5-fachen des RAM fest - macht nicht so richtig Sinn, bei 8 GiB RAM 12 GiB Swap zu haben, oder?

[/OT]

MfG Dalai

[Bernhard Geyer]

Zitat:

Zitat von Dalai (Beitrag 1320871)

[OT]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320865)

Seit gefühlt 20 Jahren lässt man die größer der Auslagerungsdatei automatisch von Windows bestimmen. Nur in Spezialfällen stellt man selbst einen Wert ein.

Dem kann ich nicht zustimmen. Es ist immer zu bevorzugen, der Auslagerungsdatei eine feste Größe zu geben. Dadurch gibt es - wenn eh schon ausgelagert werden muss - keine Fragmentierung durch die nicht-dynamische Größe, was die Zugriffsgeschwindigkeit nochmals drastisch reduzieren würde. Außerdem legt Windows immer eine Mindestgröße von vom 1,5-fachen des RAM fest - macht nicht so richtig Sinn, bei 8 GiB RAM 12 GiB Swap zu haben, oder?

[/OT]

MfG Dalai

So. Dann erklär mir doch mal genau wie bei meiner SSD die Fragmentierung zu höherer Performance führt?
Wie soll diese Defragmentieren dazu führen das der SSD-Controller die Daten schneller bekommt?

[Dalai]

[OT]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320872)

So. Dann erklär mir doch mal genau wie bei meiner SSD die Fragmentierung zu höherer Performance führt?
Wie soll diese Defragmentieren dazu führen das der SSD-Controller die Daten schneller bekommt?

Bei SSDs spielt die Fragmentierung keine Rolle, wohl aber der verfügbare Speicherplatz, so dass auch dort anzuraten ist, eine feste Größe zu benutzen. Es ging übrigens gar nicht um Defragmentierung (Swap lässt sich mit Bordmitteln eh nicht verarzten) sondern um das Vermeiden von Fragmentierung durch dynamische Größe.

[/OT]

MfG Dalai

[Sel2012]

[QUOTE=HolgerX;1320866][QUOTE=Sel2012;1320838]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1320835)

...
Somit besteht dein Projekt dann aus einer (kleinen) Exe und 3 weiteren Dateien.
...

Jetzt muss ich nur noch das Geheimnis lüften, wie die App die ausgelagerten Dateien(ordner) anlegt. Das Endprodukt muss wohl res/ sein. Siehe z.B. http://developer.android.com/guide/t...resources.html
Mit MkDir allein komme ich auch nicht weiter.
Kann mir jemand bitte den Code nennen?

[HolgerX]

OK..

Du brauchst einmal ein Tool, welches Dir die Dateien (auf deinem Entwicklungsrechner) erstellt und dann deine auszuliefernde App, welche die Daten nach dem gleichen Basis-Prinzip wieder einliest.

Zitat:

raw/
Arbitrary files to save in their raw form. To open these resources with a raw InputStream, call Resources.openRawResource() with the resource ID, which is R.raw.filename.

However, if you need access to original file names and file hierarchy, you might consider saving some resources in the assets/ directory (instead of res/raw/). Files in assets/ are not given a resource ID, so you can read them only using AssetManager.

http://developer.android.com/referen...etManager.html

Hier kannst Du die Dateien dann drinnen mit ausliefern. (Denke ich ;) )
Mit dem AssetManager (gibs den unter Delphi ?) kann dann darauf als Stream of Bytes zugegriffen und somit in deine App eingelesen werden.

Im Prinzip nichts anderes als ein FileStream/MemoryStream.

(Alles nur anhand der unter den Links geschriebenen Infos. Habe noch keine Erfahrungen mit Mobile/Android)

[Mavarik]

Zitat:

Zitat von HolgerX (Beitrag 1320974)

Du brauchst einmal ein Tool, welches Dir die Dateien (auf deinem Entwicklungsrechner) erstellt und dann deine auszuliefernde App, welche die Daten nach dem gleichen Basis-Prinzip wieder einliest.
Stimmt... Das schreibt man eben mal schnell

Zitat:

Zitat von HolgerX (Beitrag 1320974)

Mit dem AssetManager (gibs den unter Delphi ?) kann dann darauf als Stream of Bytes zugegriffen und somit in deine App eingelesen werden.

Und warum soll ich diese 3 Zeiler nicht in Delphi schreiben?

Ungepackt geht es so..

Delphi-Quellcode:

var
  RS : TResourceStream;
begin
  RS := TResourceStream.Create(HInstance,'MeinBild',RT_RCDATA);
  try
    RS.SavetoFile(Path+'MeinBild.jpg');
  finally
    RS.Free;
  end;
end;

Dann noch eine Bild.RC erzeugen mit folgendem Inhalt:

Meinbild RCDATA ".\MeinBild.jpg"

[HolgerX]

Mein Vorschlag ging darum, die Texte, Bilder, MP3s.. in separate Dateien auszulagern und dann zur Laufzeit nach zu laden.

Damit die (auszuliefernde) App bereits die Dateien mitbringt, müssen diese ja erstmal mit einem Tool erstellt werden.

Dieses Tool ist klar ein selbst geschriebenes Tool mit Delphi.

Alternativ können alle Texte, Bitmaps und Sounddateien auch in eine z.B. SQLLite DB gepackt und mit ausliefert werden.

Ob hierfür eine Datenbank notwendig ist... ?

Mit dem Tool werden die Dateien einfach in einen File-Stream der Reihe nach gespeichert (mit vorangestellter Dateigröße) und dann von seiner App per z.B. AssetManager in der gleichen Reihenfolge wieder aus dessen Byte-Stream gelesen.

Somit ist eben nicht alles in einer dicken App, sondern es können neue Texte/Bilder.. durch einfaches Austauschen seiner (externen) Files aktualisiert werden, ohne die App neu zu compilieren um die Ressourcen einzufügen.

(So war es jedenfalls unter Windows mit den .res Dateien, wenn sich an denen etwas verändert hat)

Wie das genau unter Mobile funktioniert, kann ich nicht sagen, da ich in dieser Richtung noch nicht entwickelt habe.

[Mavarik]

Zitat:

Zitat von HolgerX (Beitrag 1321315)

Wie das genau unter Mobile funktioniert, kann ich nicht sagen, da ich in dieser Richtung noch nicht entwickelt habe.

Datenbank kann man machen muss man aber nicht.

Ich nehme immer gerne alles in die Exe als gepackte Resource... Dann funktioniert es gleich unter Windows und mobile.

Ansonsten kann man für die mobilen Plattformen natürlich in apk/ipa auch externe Dateien mitliefern...

Da kann man natürlich dann einfach alle Dateien angeben und schwupp liegen die auf dem Device...

[Sir Rufo]

Es gibt ja auch noch den Bereitstellungs-Manager ;)

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1321327)

Es gibt ja auch noch den Bereitstellungs-Manager ;)

Ja das ist der "Name"... Für

Zitat:

Zitat von Mavarik (Beitrag 1321321)

Ansonsten kann man für die mobilen Plattformen natürlich in apk/ipa auch externe Dateien mitliefern...

Da kann man natürlich dann einfach alle Dateien angeben und schwupp liegen die auf dem Device...

:stupid:

[HolgerX]

Der 'Vorschlag' zum auslagern kommt daher, dass ich immer gerne 'Daten' (wie hier die Texte, Bilder und MP3s) aus meiner EXE heraushalten will.

Das hat den Vorteil, dass diese ausgetauscht werden können, ohne die Exe neu zu compilieren.

Zusätzlich können die Externen Daten/Dateien sequenziell eingelesen werden, also nicht wie im Falle von Ressourcen direkt beim Programmstart. Es wird aus diesen Dateien nur dass eingelesen, was wirklich gerade gebraucht wird.

Auch kann für diese externen 'Archive' eine Kompression genutzt werden.

[Mavarik]

Zitat:

Zitat von HolgerX (Beitrag 1321374)

Der 'Vorschlag' zum auslagern kommt daher, dass ich immer gerne 'Daten' (wie hier die Texte, Bilder und MP3s) aus meiner EXE heraushalten will.

Das hat den Vorteil, dass diese ausgetauscht werden können, ohne die Exe neu zu compilieren.

Stimmt... compilieren dauert ja auch immer so lange...

Zitat:

Zitat von HolgerX (Beitrag 1321374)

Zusätzlich können die Externen Daten/Dateien sequenziell eingelesen werden, also nicht wie im Falle von Ressourcen direkt beim Programmstart. Es wird aus diesen Dateien nur dass eingelesen, was wirklich gerade gebraucht wird.

Also ich lade die Daten aus der Resource wenn ich die brauche... und nicht jedes mal beim Programmstart. Ggf. auch nur beim 1. Start oder falls der User eine Datei die wichtig war gelöscht hat...

Dadurch bleibt mein Programm immer konsistent und lauffähig.

Zitat:

Zitat von HolgerX (Beitrag 1321374)

Auch kann für diese externen 'Archive' eine Kompression genutzt werden.

Kann ich bei einer Resource genau so...