Alternative zu loadfromfile viele kleine Dateien

[bluescreen25]

Für eine skinroutinelade ich viele kleine Grafikdateien (jpg,png) zum erstellen der Form einzeln ein, da die Koordinaten und Dateinamen in einer Ini hinterlegt sind.

Die Routine braucht sehr lange beim Start des Programms, weil es eben viele kleine Dateien sind (mehr als 300) und der Festplattenzugriff lahm ist.

Eine große Datei würde schneller laden als die vielen kleinen.

Gibt es eine Möglichkeit, alle Dateien in ein zip zu packen und es in der skinroutine beim starten zu entpacken und daraus dann die Bilder wieder zu nutzen ?

sprich aus der ini wiedrum die Koordinaten zu entnehmen und die im Speicher entpackten Dateien dann zu platzieren ?

Wäre das im Längen schneller als jetzt ?

[calculon]

Nein, da die Pack/Entpack-Rechenzeit ja dann noch miteinfließt, wenn du am Code ansonsten nichts änderst. Es dauert also IMHO noch länger...

[Klaus01]

Müssen die GrafikDateien denn austauschbar sein, wenn nein dann würde es
sich eventuell anbieten die Dateien als Resource in das Programm direkt einzubinden.

Grüße
Klaus

[bluescreen25]

Zitat:

Zitat von Klaus01

Müssen die GrafikDateien denn austauschbar sein, wenn nein dann würde es
sich eventuell anbieten die Dateien als Resource in das Programm direkt einzubinden.

Grüße
Klaus

Es geht im einen Skin....also wird es auch noch andere Designs geben.....die ini bestimmt, wie viele Elemente (Bilder) verwendet werden....

[bluescreen25]

Zitat:

Zitat von calculon

Nein, da die Pack/Entpack-Rechenzeit ja dann noch miteinfließt, wenn du am Code ansonsten nichts änderst. Es dauert also IMHO noch länger...

Es geht mir nicht um eine Kompression, sondern um ein zusammenhängendes Datenpaket bestehend aus den vielen Einzeldateien, die aber nacher im Programm wieder einzeln ansprechbar sein müssen..... die jpg und png's sind ja schon gepackt....

Ich wollte mir die vielen Festplattenzugriffe sparen...

[Gausi]

Ich würde nach Möglichkeit die einzelnen Grafiken in eine Datei packen und dann mit CopyRect und ähnlichem aus dieser einen Grafik die einzelnen Skin-Grafiken rausziehen. Geht natürlich nur, wenn die Bilder eine fest definierte Größe haben.

[SirThornberry]

das einfachste ist du schreibst alle deine Skindateien hintereinander in die Datei und speicherst eben die Positionen in eine die Ini (oder sogar mit in diese Datei)

Folgendes ist ungetestet sollte aber funktionieren.

Delphi-Quellcode:

var
  lFile     : TMemoryStream;
  lBigFile  : TFileStream;
  lCount    : Integer;
begin
  lFile := TMemoryStream.Create();
  lBigFile := TFileStream.Ceate(Filename, fmCreate);
  for lCount := 0 to DateiListe.Count - 1 do
  begin
    lFile.LoadFromFile(DateiListe.Strings[lCount];
    
    Ini.WriteString('Files', 'File' + IntToStr(lCount), DateiListe.Strings[lCount]);
    Ini.WriteInteger('Files', 'FilePos' + IntToStr(lCount), lBigFile.Position);
    Ini.WriteInteger('Files', 'FileSize' + IntToStr(lCount), lFile.Size);
    
    lFile.Position := 0;
    lBigFile.CopyFrom(lFile, lFile.Size);
  end;
  lBigFile.Free;
  lFile.Free;
end;

[bluescreen25]

Zitat:

Zitat von Gausi

Ich würde nach Möglichkeit die einzelnen Grafiken in eine Datei packen und dann mit CopyRect und ähnlichem aus dieser einen Grafik die einzelnen Skin-Grafiken rausziehen. Geht natürlich nur, wenn die Bilder eine fest definierte Größe haben.

Hmm, feste Größen haben diese natürlich nicht, weil auch die Elemente nicht fix an der selben Stelle landen.

dann müsste man in der ini einmal die Source und die Destination-Koordinaten angeben ???

Das Problem wäre dann noch, das es sich um png und jpg handelt....lässt sich schlecht zusammenfassen...und nur png funktioniert aus anderen Gründen nicht....

hmmm oder die jpg's in ein Bild zusammen und die png's in einem anderen ?

[SirThornberry]

Das zusammenfassen würde ich lassen denn dann müsstest du das Bild in einem Stück laden und da kann es zu Problemen kommen. Denn dazu müsstest du ein zusammenhängendes Stück Speicher haben was groß genug für alle Grafiken ist.

[franktron]

In der Codelib ist ein Programm zum zusammenfügen vieler kleiner Daten zu einer und ist auch recht schnell

[Bernhard Geyer]

Zitat:

Zitat von bluescreen25

Eine große Datei würde schneller laden als die vielen kleinen.

Ist wirklich das Laden von Festplatte das Problem oder lädst du die Dateien in entsprechende TImage/TBitmap/...-Komponenten? von welchen Zeiten sprechen wir?

[SirThornberry]

@Bernhardt: Das ist wirklich das Problem. Ich habe auch bereits die Erfahrung gemacht dass, das einlesen mehrere Dateien sehr lange dauert. Selbst wenn man die Dateien nicht liest sondern immer nur öffnet und wieder schließt vergeht eine menge Zeit.

[bluescreen25]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von bluescreen25

Eine große Datei würde schneller laden als die vielen kleinen.

Ist wirklich das Laden von Festplatte das Problem oder lädst du die Dateien in entsprechende TImage/TBitmap/...-Komponenten? von welchen Zeiten sprechen wir?

bis zu 30 sek Ladezeit bei einem schwachen Rechner PIII bis die Skinroutine aus der ini die einzelnen Button-Up und Button-Down Properties sowie im Grunde die gesamte Grafik von mehreren Forms zusammengebaut hat.(Background,Slider,Label,Buttons etc).
Bei einem PIV etwa 5-10 sek.

Etwa 250-300 Einzelgrafiken als png mit 5-100 Kb und etwa Gesamt 8 MB .

Ich nutze die pngimage-Kompo damit png' nutzbar sind, lade die Bilder mit Loadfromfile direkt in die Form.

[bluescreen25]

Zitat:

Zitat von SirThornberry

das einfachste ist du schreibst alle deine Skindateien hintereinander in die Datei und speicherst eben die Positionen in eine die Ini (oder sogar mit in diese Datei)

Folgendes ist ungetestet sollte aber funktionieren.

Delphi-Quellcode:

var
  lFile     : TMemoryStream;
  lBigFile  : TFileStream;
  lCount    : Integer;
begin
  lFile := TMemoryStream.Create();
  lBigFile := TFileStream.Ceate(Filename, fmCreate);
  for lCount := 0 to DateiListe.Count - 1 do
  begin
    lFile.LoadFromFile(DateiListe.Strings[lCount];
    
    Ini.WriteString('Files', 'File' + IntToStr(lCount), DateiListe.Strings[lCount]);
    Ini.WriteInteger('Files', 'FilePos' + IntToStr(lCount), lBigFile.Position);
    Ini.WriteInteger('Files', 'FileSize' + IntToStr(lCount), lFile.Size);
    
    lFile.Position := 0;
    lBigFile.CopyFrom(lFile, lFile.Size);
  end;
  lBigFile.Free;
  lFile.Free;
end;

Mit Streams habe ich noch nichts gemacht. Kannst du mir die vorgehensweise hier noch etwas deutlicher erklären ?
Soll ich eine eigene Application schreiben, womit man alle im sagen wir mal einem best.Ordner befindlichen Dateien in eine zusammenfasst sowie eine ini erstellen lassen, die die Positionen angibt ? Dann im Hauptprogramm die ini auslesen und anhand der Positionen die eigendlichen Dateien innerhalb der erstellten BigDatei finden ??

[Bernhard Geyer]

Zitat:

Zitat von bluescreen25

bis zu 30 sek Ladezeit bei einem schwachen Rechner PIII bis die Skinroutine aus der ini die einzelnen Button-Up und Button-Down Properties sowie im Grunde die gesamte Grafik von mehreren Forms zusammengebaut hat.(Background,Slider,Label,Buttons etc).

Ich denke nicht das das Laden der Dateien das Problem ist wenn jede Datei nur einmal geladen werden muss (und per Caching wiederverwendet wird). Ich würde mal auf das eigentliche Laden, sprich Datei "erkennen" und in Speicher laden auf < 1 Sekunde tippen. Vermutlich ist der Rest das eigentliche Problem das die Skinning-Lösung einfach zu viel CPU-Zeit verbrät ("Entpacken" PNG, ...). Mit AQTime (Evtl. reicht fürs erste die Trial-Version) sollte das in 1 Minute geklärt sein.

Mußt Du wirklich zum Programmstart alle 300 Dateien laden oder könnte das nicht incrementell erfolgen wenn die Dateien benötig werden?

[bluescreen25]

Zitat:

Zitat von franktron

In der Codelib ist ein Programm zum zusammenfügen vieler kleiner Daten zu einer und ist auch recht schnell

Hmm ich schau mir das mal an hört sich gut an...muss die nur noch wieder ins Mainprogramm auslesen können....

[Bernhard Geyer]

Zitat:

Zitat von Bernhard Geyer

Mit AQTime (Evtl. reicht fürs erste die Trial-Version) sollte das in 1 Minute geklärt sein.

Oder zuvor mal die CPU-Nutzung während Programmstart kontrollieren. Liegt die (für eine CPU) bei 100% so ist es m.E. definitiv nicht die Festplatten-Ladezeit welche das Problem verursacht.

[bluescreen25]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von bluescreen25

bis zu 30 sek Ladezeit bei einem schwachen Rechner PIII bis die Skinroutine aus der ini die einzelnen Button-Up und Button-Down Properties sowie im Grunde die gesamte Grafik von mehreren Forms zusammengebaut hat.(Background,Slider,Label,Buttons etc).

Ich denke nicht das das Laden der Dateien das Problem ist wenn jede Datei nur einmal geladen werden muss (und per Caching wiederverwendet wird). Ich würde mal auf das eigentliche Laden, sprich Datei "erkennen" und in Speicher laden auf < 1 Sekunde tippen. Vermutlich ist der Rest das eigentliche Problem das die Skinning-Lösung einfach zu viel CPU-Zeit verbrät ("Entpacken" PNG, ...). Mit AQTime (Evtl. reicht fürs erste die Trial-Version) sollte das in 1 Minute geklärt sein.

Mußt Du wirklich zum Programmstart alle 300 Dateien laden oder könnte das nicht incrementell erfolgen wenn die Dateien benötig werden?

Wenn die benötigt werden und dann mit loadfromfile reinkommen, dann gibt es bei Menüwechsel (Formwechsel) kurze Denkpausen....mind. einmal um ein noch nicht geöffnetes Menü zu initialisieren ,deshalb haben wir ja die Dateien direkt eingelesen, damits nacher flüssig läuft.

Hatte alles ein Für und Wider...aber die flüssige Nutzung war erstmal wichtiger...

Enthalten im Programm sind ein Audio und Videoplayer und wenn die resumen und noch der Menüwechsel "neu" geladen werden muss, dann hakt es !

Die App sollte auch auf schwacheren PCs flüssig laufen, an Speicher haperts ja meist nicht , die CPUs sind teuer oder teilweise für diese Anwendung nicht lohnenswert aufrüstbar...

[bluescreen25]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Bernhard Geyer

Mit AQTime (Evtl. reicht fürs erste die Trial-Version) sollte das in 1 Minute geklärt sein.

Oder zuvor mal die CPU-Nutzung während Programmstart kontrollieren. Liegt die (für eine CPU) bei 100% so ist es m.E. definitiv nicht die Festplatten-Ladezeit welche das Problem verursacht.

Die CPU-Last ist hoch, aber warum auch nicht ? Eingeschränkt sind die Skinladeroutinen für die einzelnen Parts wie Buttons oder Label durch Application.processmessage und somit kann man in Windows theoretisch noch was anderes machen. Die Laderoutine in einer Schleife darauf bedacht erst ein Menü zu initialisieren , dann alle Buttons zu setzen usw...

Setze ich keine Application.proc.... dann schafft ein fixer Rechner das in 4 Sek und ein langsamer etwa in 20 sek...nur dann kann ich Windows nicht mehr bedienen...

[himitsu]

du könntest auch erstmal statt TIni... TMemIni verwenden ... TIni und Co. greifen jedesmal auf die WinAPI zu und die öffnen für jeden Wert die INI neu und lesen nur den einen Wert aus (wobei da natürlich alles vorherige jedesmal neu ausgewertet werden muß.

TMemIni ließt die Datei nur einmal in den Arbeitsspeicher und ließt dann von dort die Werte.

[Bernhard Geyer]

Zitat:

Zitat von bluescreen25

Die CPU-Last ist hoch, aber warum auch nicht ?

Hohe CPU lastet deutet darauf hin das das Laden von Dateien kein beschränkender Faktor ist sondern wirklich CPU-Werkeln (wie "entpacken" von PNG oder Zeichnen auf Canvas) das Hauptproblem darstene.

[bluescreen25]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von bluescreen25

Die CPU-Last ist hoch, aber warum auch nicht ?

Hohe CPU lastet deutet darauf hin das das Laden von Dateien kein beschränkender Faktor ist sondern wirklich CPU-Werkeln (wie "entpacken" von PNG oder Zeichnen auf Canvas) das Hauptproblem darstene.

Ok, nur wenn ich alles auf einmal laden und initialisieren will wie oben erwähnt, bleibt mir ja nur noch ein Optimieren.
Wenn ich die Maus-Over-Grafiken weglasse, so habe ich "fast" doppelten Speed, macht sich ungemein bemerkbar.(soeben kurz getestet)
Wenn ich den Tipp von himitsu mit der TMemini sowie die vielen kleinen Dateien in eine große umwandel, dann sollte es doch schon ein Fortschritt sein?

Oder hast du noch einen anderen Gedanken ? Denn irgendwie muss ich ja die Grafiken einlesen und auch zeichnen.

[bluescreen25]

Zitat:

Zitat von himitsu

du könntest auch erstmal statt TIni... TMemIni verwenden ... TIni und Co. greifen jedesmal auf die WinAPI zu und die öffnen für jeden Wert die INI neu und lesen nur den einen Wert aus (wobei da natürlich alles vorherige jedesmal neu ausgewertet werden muß.

TMemIni ließt die Datei nur einmal in den Arbeitsspeicher und ließt dann von dort die Werte.

Danke für den Tipp, das wusste ich noch gar nicht...

[Bernhard Geyer]

Zitat:

Zitat von bluescreen25

Wenn ich den Tipp von himitsu mit der TMemini sowie die vielen kleinen Dateien in eine große umwandel, dann sollte es doch schon ein Fortschritt sein?

Ich würde darauf Tippen das dies maximal 1 Sekunde Vorteil bringt. Check es wirklich mal mit einem Performance-Tester. Evtl. ist ja ganz woanders noch ein Performancegrab (Repainting kompletter Mainform nach jeder geladenen Skin-datei).

[SirThornberry]

@Bernhard Geyer: Ich tippe darauf das es an den Dateien liegt. Grund: ich hatte schon gleiches Problem. Mehrere hundert Dateien in einem Ordner und es hat eine halbe Ewigkeit gedauert. Das ganze in eine einzelne Datei gestopft und es ist nur so durchgeflutscht

[bluescreen25]

Zitat:

Zitat von SirThornberry

@Bernhard Geyer: Ich tippe darauf das es an den Dateien liegt. Grund: ich hatte schon gleiches Problem. Mehrere hundert Dateien in einem Ordner und es hat eine halbe Ewigkeit gedauert. Das ganze in eine einzelne Datei gestopft und es ist nur so durchgeflutscht

Kannst du mir zu deinem Vorschlag noch etwas näher erläutern ?

[Bernhard Geyer]

Zitat:

Zitat von SirThornberry

@Bernhard Geyer: Ich tippe darauf das es an den Dateien liegt.

Wetten wir ein Bier? Ausbezahlung auf der EKON11 - Falls du da auch dort bist.

[bluescreen25]

Bohhr :shock: Ich habe alle TIniFile-Einträge gegen TMemIniFile-Einträge getauscht, jetzt habe ich 400% mehr Speed....

Gibt es dabei einen Haken ??