ZPAQ's Face - eine Benutzeroberfläche zur effizienten Datenkompression v1.0.c

[Winni]

@winni:

Ich habe ein wenig geforscht und einige der unerklärlichen Bugs konnten behoben werden, indem ich den Outputstream nicht direkt in das Memo, sondern in eine StringList lade.

Ich habe eine experimentelle Version diesem Beitrag angehängt.
In der experimentellen Version ist auch das "-s1"-Workaround eingeflossen.

Falls Du Zeit und Lust hast wäre es super, wenn Du mir zu zwei Dingen mal Rückmeldung geben könntest:
(1) --> Funktioniert die Anzeige bei Dir jetzt so wie gewünscht?
(2) --> Kannst mal testweise das Workaround "add('-s1')" ausklammern und mir kurz schreiben, ob und wenn ja zu welchem Zeitpunkt Du eine Ausgabe im Memo siehst?

Danke Dir im Voraus!

Beste Grüße vom Euklid

Hi!

1. Wunderbar - er zeigt alles an wie er soll
2. -s1 raus - nun wird's merkwürdig. Er zeigt gar nix an und dann beim Ende aber nur ab 77%:

77.83% 0:00:23 [20753..21674] 67029314 -method 46,7,0
81.21% 0:00:19 [21675..22608] 67025529 -method 46,7,0
84.61% 0:00:24 [22609..23540] 67079971 -method 46,6,0
87.98% 0:00:20 [23541..24470] 67064818 -method 46,7,0
91.37% 0:00:14 [24471..25328] 67055622 -method 46,8,0
94.75% 0:00:08 [25329..26264] 67049496 -method 46,9,0
98.15% 0:00:02 [26265..27226] 67064675 -method 46,6,0
100.00% 0:00:00 + /MMedia/Filme/007/Sag_Niemals_Nie.mpg -> Sag_Niemals_Nie.mpg 1980783988
100.00% 0:00:00 [27227..27821] 36957844 -method 46,22,0
1 +added, 0 -removed.

By the way 1: Falls -s1 drinnen bleibt: da fehlt nach der " x added x removed" Meldung noch der selstart auf das letzte Memo-Zeichen.

By the way 2: Für später: Seine "estimated time" is ja wohl voll für die Wicken. Irgendwo bei 50% springt er von 13 Sekunden auf 1:05. Das würde sich in irgend ner Anzeige schlecht machen.

Und zum Schluß meldet er zweimal 100%, steht da aber ewig rum, bis er sich fertig meldet.
Was meditiert er da???

Keep on hacking

Winni

[wennerer]

Hi,
ich hab den Output mal getestet (hab nichts ausgeklammert). Siehe Anhang.
Viele Grüße
Bernd

[af0815]

Die Anzahl der auf dem jeweiligen Rechner vorhandenen HyperThreads lässt sich per Software ermitteln .
Leider ist das zwischen Windows und Linux immer noch nicht vereinheitlicht.

Als Hinweis, FPCUpDeluxe verwendet die NumCPULib, die ist auf verdammt viele Varianten von Betriebsystemen optimiert. Siehe auch https://github.com/Xor-el/NumCPULib4Pascal. Ist mit MIT Lizenz zu verwenden.

[Winni]

Hallo Euklid.

Ich hab noch einmal ausgiebig alles Mögliche getestet, hab aber ohne -s1 keine Echtzeit-Meldungen entlocken können.

* Ich hab dir Process.Priority runtergesetzt bis auf ZPAQ.Priority:= ppIdle - kein Erfolg.

* Ich hab die Anzahl der HyperThreads halbiert, damit das System genug Luft zum "atmen"" hat - kein Erfolg.

* Dann hab ich den loop verfolgt, der die eingelesene StringList ins Memo schreibt. Das wird zwar regelmäßig aufgerufen - die StringList ist aber immer leer mit Ausnahme des letzten Aufrufs.

Ich bin jetzt erstmal mit meinen Ideen am Ende:
wenn keine schlaue Idee mehr kommt müssen wir mir -s1 arbeiten.

Zur Erinnerung:
Suse Tumbleweed, Lin64, fpc 3.04, Lazarus 2.10
Genug RAM hat er auch: 16 GB. Davon nutzt er höchstens 10.x GB.

Winni

[Euklid]

Hallo Winni,

danke für Deine gründliche Nachforschung!
Ich bin da mit meinem Latein am Ende jetzt...

... ich schreibe Dir und den Anderen morgen genauer, bin heute leider nicht mehr zu unserem gemeinsamen Hobby gekommen

Liebe Grüße und bis morgen!

- Euklid

[Euklid]

Dieser Beitrag kann von den Moderatoren wieder gelöscht werden, sry.

[Euklid]

Hallo Andy,

zum Beispiel...

Code: Alles auswählen

OpenDialog1.Filter :='Datei(*.zpac)|*.zpac';

Danke Dir! Funktioniert hervorragend!

und baue mal noch eine Funktion ein das man versehentliche Dateien oder Ordner auch aus dem Archiv wieder löschen kann
vor dem Archiv speichern
als Anregung

Jawoll, finde ich eine gute Idee. Das ist aktuell für die Version 1.1 geplant:

viewtopic.php?p=115847#p115847

Viele Grüße und danke für Deine Rückmeldung!

Alexander alias Euklid

[Euklid]

Hi,
ich hab den Output mal getestet (hab nichts ausgeklammert). Siehe Anhang.
Viele Grüße
Bernd

Sehr gut, vielen Dank Bernd!

Genau so soll sich die Ausgabe verhalten. Dann weiß ich jetzt, dass es sich jetzt auch bei Dir (und auch Winni) so verhält, wie es sich verhalten soll

Liebe Grüße, Euklid

[Euklid]

Hallo Winni,

vielen Dank für Deine ausführlichen Tests!

1. Wunderbar - er zeigt alles an wie er soll
2. -s1 raus - nun wird's merkwürdig. Er zeigt gar nix an und dann beim Ende aber nur ab 77%:

Ja, so habe ich das auch beobachtet. Ist echt merkwürdig!

By the way 1: Falls -s1 drinnen bleibt: da fehlt nach der " x added x removed" Meldung noch der selstart auf das letzte Memo-Zeichen.

Hmm. Ich dachte, das hätte ich:

Code: Alles auswählen

procedure THauptfenster.LetzteAusgabenzeilenInsMemo(Anzahl: integer);
var Anfang, n: integer;
begin
  [...]
  AusgabeMemo.SelStart := Length(AusgabeMemo.Text);                               //Das Ausgabememo wird so eingestellt, dass die letzte Zeile gesehen werden kann.
  AusgabeMemo.Refresh;                                                            //Neuen Inhalt anzeigen.

end;  //LetzteAusgabenzeilenInsMemo 

By the way 2: Für später: Seine "estimated time" is ja wohl voll für die Wicken. Irgendwo bei 50% springt er von 13 Sekunden auf 1:05. Das würde sich in irgend ner Anzeige schlecht machen.

Und zum Schluß meldet er zweimal 100%, steht da aber ewig rum, bis er sich fertig meldet.
Was meditiert er da???

hahaha
Also der Fortschritt wird von zpaq nicht gut berechnet.
zpaq packt die Dateien in Blöcken von standardmäßig 64MiB. Sobald er ausreichend Dateien zum Komprimieren geparst hat, fängt er mit dem Komprimieren an. Die Phase des Komprimierens ist das, was Du als Meditieren bezeichnest haha

... um das besser zu machen müssten wir in zpaq selbst eingreifen. Mangels C++-Kenntnisse scheidet diese Möglichkeit für mich zumindest aus...

Ich hab noch einmal ausgiebig alles Mögliche getestet, hab aber ohne -s1 keine Echtzeit-Meldungen entlocken können.

* Ich hab dir Process.Priority runtergesetzt bis auf ZPAQ.Priority:= ppIdle - kein Erfolg.

* Ich hab die Anzahl der HyperThreads halbiert, damit das System genug Luft zum "atmen"" hat - kein Erfolg.

* Dann hab ich den loop verfolgt, der die eingelesene StringList ins Memo schreibt. Das wird zwar regelmäßig aufgerufen - die StringList ist aber immer leer mit Ausnahme des letzten Aufrufs.

Das ist ja krass

Vielen Dank für Deine Umfangreichen Tests!
Wie interpretierst Du das? Bug in der LCL? Bug in zpaq?

wenn keine schlaue Idee mehr kommt müssen wir mir -s1 arbeiten.

Machen wir so!

Zur Erinnerung:
Suse Tumbleweed, Lin64, fpc 3.04, Lazarus 2.10

ui - ist Lazarus 2.10 schon draußen?

Alles klar, winni! Danke für die ausführlichen Rückmeldungen

Beste Grüße, Euklid

[Winni]

Hallo Winni,

danke für Deine gründliche Nachforschung!
Ich bin da mit meinem Latein am Ende jetzt...

Hallo!

Ich hab jetzt mal geforscht, ob das merkwürdige Verhalten mit der Status-Ausgabe unter Linux an zpaq oder an fpc/Lazarus liegt und hab zpaq ausgiebig an der bash getestet.

Ohne langschweifige Ausführungen:

Sobald man zpaq in eine Pipe schickt, wird die komplette Status-Information nur am Ende im Sück ausgegeben. Diverse Tests. Es liegt also an der fehlerhaften Implementierung von fpaq unter Linux.

Der Readme gibt dann auch zu, dass das Ganze eine Windows-Entwicklung ist und der Port nach Linux bzw. Mac danach erfolgt worden ist. Eben nicht von einem Linux-Mann.

Das heisst, wir müssen mit dem Parameter -s1 leben und diese Infos verarbeiten.

Winni

[reiter]

Auf dem mac das selbe Verhalten wie winni schon geschildert hat..

Die Ausgabe erfolgt erst wenn die Komprimierung abgeschlossen ist..
Und bei dem Testprogramm Output-Forschung.. schneidet er die Hälfte ab

[Euklid]

@winni und @andi:

Alles klar - puh, das hat einige Mühe gekostet.

Danke für Euer Feedback, dann belassen wir es beim Parameter "-s1". Sooo schlimm finde ich das garnicht mal

Macht Spaß, mit Euch zusammen zu arbeiten! Ich versuche gerade, die letzten Bugs zu beheben und die letzten Ideen einzuarbeiten. Werde damit heute wohl nicht fertig, im Laufe der Woche kommt dann der Release Cadidate

Liebe Grüße, Euklid

[Winni]

Hallo!

Nun holen wir uns die Infos mittels -s1
und die Infos sind recht merkwürdig, zumindest bei m3 bis m5

Irgendwo zwischen 55% und 97%. wechselt er den Algorithmus - was mit einem großen Sprung der "estimated time" einhergeht. Zweitens steht er ewig auf 100% rum - was macht er da?

Ich hab testweise eine StopUhr eingebaut.
Ein sehr merkwürdiges Ergebnis sah so aus:
1 GB mpg, m5
% --------Zeit
0% .. 97% : 00:19
97%..100%: 10:41
100%..Ende: 14:12

Wenn man das in einen Progressbar einbaut, denken die Leute, man will sie veräppeln.

Und die "langsamen" 100% sind geklärt:
Er arbeitet nur von Memory zu Memory bis 100% - danach fängt er an, in die Datei zu schreiben.
Diesen Fortschritt kann man natürlich per filesize abfragen, wobei man natürlich nicht weiss, wie groß der komprimierte file ist.

Man könnte natürlich irgendeine "wackelige" Heuristik einbauenn?!

Winni

[Euklid]

Ja. Ich fühle mich ein wenig an die Fortschrittsbalken zu meiner Windows-Zeit zurückerinnert...


Eine Heuristik macht nur Sinn, wenn man sie selbstlernend macht:
Nach der 1. Komprimierung merkt er sich die Zeiten und rechnet dann bei jedem neuen Archiv hoch...

- Euklid

[Winni]

Hi

Nach dem ganzen Gefrickel und Gefruste nochmal ne Erfolgsmeldung:

allCountries.csv ist eine Geo-Datenbank mit 11 Mio Datensätzen (Städte, Berge, Flughäfen , ....).
alles UTF8, TAB separiert

1.358 GB Original 10.928.276 Datensätze
0.301 GB 22% Download als ZIP
0.138 GB 10% zpaq m5

zpaq m5 braucht allerdings 19:24 Minuten auf meinem Rechner.
Und selbst das simple KPatience zum Zeitvertreib "humpelt" währenddessen:
alle CPUs am Anschlag!

Tschüß,
Winni