Alternative zu loadfromfile viele kleine Dateien

[Bernhard Geyer]

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 von Bernhard Geyer:

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 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 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 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 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 von Bernhard Geyer:

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 von Bernhard Geyer:

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.