F2046 Zu wenig Arbeitsspeicher (Delphi)

[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...