sajder
Anmeldungsdatum: 1. März 2017
Beiträge: Zähle...
|
Hallo. Wieso ist Thunar beim kopieren von Daten auf ein USB-Stick langsamer im vergleich zu 'cp' per Terminal? Das sind die Durchschnittswerte nach mehreren Vorgängen, auf zwei unterschiedlichen USB-Sticks. Kopiervorgang auf USB2 16GB Transcend: Bei 100MB ist Thunar 5 Sekunden langsamer im vergleich zu 'cp' per Terminal. Bei 500MB ist Thunar 25 Sekunden langsamer im vergleich zu 'cp' per Terminal.
Kopiervorgang auf USB2 64GB Transcend: Bei 100MB ist Thunar 20 Sekunden langsamer im vergleich zu 'cp' per Terminal. Bei 500MB ist Thunar 55 Sekunden langsamer im vergleich zu 'cp' per Terminal.
Liegt es an Thunar_1.6.12 in der aktuellen Xubuntu_17.10 Version? Leider hab ich kein vergleich zu früheren Versionen. Da mir, dass erst jetzt aufgefallen ist.
|
picnerd
Anmeldungsdatum: 17. März 2016
Beiträge: 872
|
Kopiervorgänge über die GUI sind grundsätzlich langsamer. Die Aufgabe mit cp im Terminal auszuführen ist vielleicht aufwändiger aber halt auch schneller beim eigentlichen kopieren. Mir ist auch aufgefallen das wenn ich was kopiere mit z.B. Thunar dann ist der Prozess Augenscheinlich beendet. Möchte ich jetzt aber den z.B. USB-Stick entfernen(Aushängen) bekomme ich die Nachricht das noch Daten geschrieben werden müssen und ich noch warten muss. Warum das jetzt im einzelnen länger dauert kann ich Dir aber auch nicht erklären da mir dazu das tiefer gehende Wissen fehlt. Aber ich Tippe mal darauf das die Daten noch überprüft werden. mfg
|
Kätzchen
Anmeldungsdatum: 1. Mai 2011
Beiträge: 6647
Wohnort: Technische Republik
|
Es muss nicht sein das bei cp im Terminal der Kopiervorgang nach dem augenscheinlichen Ende abgeschlossen ist. Ich schiebe dann immer noch ein sync hinterher.
|
sajder
(Themenstarter)
Anmeldungsdatum: 1. März 2017
Beiträge: 19
|
Hätte ich wohl erwähnen sollen, meine USB-Sticks sind im 'fstab' eingetragen. Und, weil mich beim Aushängen/Auswerfen des USB-Sticks die Meldung "Daten werden geschrieben, bitte warte usw." immer störte, habe ich 'sync' mit in 'fstab' eingetragen. Seid dem ist ruhe beim Auswerfen des USB-Sticks. Dann wird es wohl an der Grafischen Oberfläche liegen, das es halt langsamer ist. Werde aber noch aus neugier eine andere Ubuntu Live Version ausprobieren. Bevor ich das Thema / Status schließe.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
picnerd schrieb: Kopiervorgänge über die GUI sind grundsätzlich langsamer.
Ist das so? Wie kommt das? Bei 1000 Minidateien, wenn für jede eine kleine "Ich verfliege mich in den Mülleimer und zerknülle währenddessen, weil das für den User voll intuitiv ist"-Animation abgespielt wird, wäre das verständlich. Aber keine Entschuldigung nach 30 Jahren und mehr grafischen Oberflächen.
Warum das jetzt im einzelnen länger dauert kann ich Dir aber auch nicht erklären da mir dazu das tiefer gehende Wissen fehlt. Aber ich Tippe mal darauf das die Daten noch überprüft werden.
Das wäre aber überraschend. Für mich zumindest.
|
picnerd
Anmeldungsdatum: 17. März 2016
Beiträge: 872
|
user_unknown schrieb:
Bei 1000 Minidateien, wenn für jede eine kleine "Ich verfliege mich in den Mülleimer und zerknülle währenddessen, weil das für den User voll intuitiv ist"-Animation abgespielt wird, wäre das verständlich. Aber keine Entschuldigung nach 30 Jahren und mehr grafischen Oberflächen.
Wenn du vor einer Windoofkiste sitzt dann tut es mir leid. Ich habe keine solche Animationen.
An den Animationen wird es wohl auch nicht wirklich liegen, wie wir schon festgestellt haben, da ja immer noch ein oder mehrere Prozesse ablaufen. Zu dem genannten sync würde ich noch das errechnen des Speicherverbrauchs und das überprüfen ob der Speicher ausreicht dazu zählen.
Bei cp im Terminal passiert das ohne zusätzliche Optionen nicht. Wenn kein Platz mehr vorhanden ist bricht der Prozess an dieser Stelle ab. mfg
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
picnerd schrieb: user_unknown schrieb:
Bei 1000 Minidateien, wenn für jede eine kleine "Ich verfliege mich in den Mülleimer und zerknülle währenddessen, weil das für den User voll intuitiv ist"-Animation abgespielt wird, wäre das verständlich. Aber keine Entschuldigung nach 30 Jahren und mehr grafischen Oberflächen.
Wenn du vor einer Windoofkiste sitzt dann tut es mir leid.
Es gibt wenig, das mir ferner liegt.
Ich habe keine solche Animationen.
An den Animationen wird es wohl auch nicht wirklich liegen, wie wir schon festgestellt haben, da ja immer noch ein oder mehrere Prozesse ablaufen. Zu dem genannten sync würde ich noch das errechnen des Speicherverbrauchs und das überprüfen ob der Speicher ausreicht dazu zählen.
Bei cp im Terminal passiert das ohne zusätzliche Optionen nicht. Wenn kein Platz mehr vorhanden ist bricht der Prozess an dieser Stelle ab.
Du meinst, wenn Du eine 1100 MB-Datei auf ein Speichermedium schreiben willst, auf dem nur 1GB Platz ist, dann fängt der Dateimanager gar nicht an zu kopieren, weil er vorab den Platz prüft?
|
Vegeta
Anmeldungsdatum: 29. April 2006
Beiträge: 7943
|
sajder schrieb: Wieso ist Thunar beim kopieren von Daten auf ein USB-Stick langsamer im vergleich zu 'cp' per Terminal?
Ich denke das lässt sich relativ leicht erklären, je nachdem wie mit Thunar kopiert wird (also ob die zu kopierende Datei sichtbar im Fenster ist oder z.B. in einem Ordner kopiert / verschoben wird, wo sie nicht zu sehen ist) passieren da mehrere Dinge im Hintergrund. Ich habe bei größeren Dateien schon öfter beobachtet, dass während des Kopiervorgangs das Thumbnail der Datei aktualisiert wurde. Wenn dies generell bei allen Dateien gemacht wird, dass da tumblerd während des Kopierens die Daten analysiert, würde dies bei einem so langsamen Medium wie einem USB-Stick diese zusätzliche Verzögerung schon erklären können. Alternativ könntest du auch mal den PCManFM Filemanager ausprobieren oder ein Programm wie Double Commander oder halt mal tumblerd deaktivieren, ob es dadurch schnell geht.
|
picnerd
Anmeldungsdatum: 17. März 2016
Beiträge: 872
|
user_unknown schrieb: Du meinst, wenn Du eine 1100 MB-Datei auf ein Speichermedium schreiben willst, auf dem nur 1GB Platz ist, dann fängt der Dateimanager gar nicht an zu kopieren, weil er vorab den Platz prüft?
Ich gebe die Frage gerne zurück. Was passiert bei einer großen zusammenhängenden Datei wie z.B. einem Film und was passiert bei der letzten von vielen kleinen Dateien (nicht Ordner)? Vegeta schrieb: Ich denke das lässt sich relativ leicht erklären, je nachdem wie mit Thunar kopiert wird (also ob die zu kopierende Datei sichtbar im Fenster ist oder z.B. in einem Ordner kopiert / verschoben wird, wo sie nicht zu sehen ist) passieren da mehrere Dinge im Hintergrund.
Wir reden ja jetzt nur vom Kopiervorgang. Beim verschieben muss zusätzlich ja noch die Quelle nachträglich gelöscht werden. Das würde zusätzlich Zeit benötigen und das von user_unknown angesprochene zerknüllen und in den Papierkorb werfen auslösen (auch wenn man es nicht sieht). mfg
|
sajder
(Themenstarter)
Anmeldungsdatum: 1. März 2017
Beiträge: 19
|
Ich habe jetzt ein paar Dateimanager verglichen, alle unter Xubuntu 17.10 installiert. Der USB-Stick wie bereits erwähnt ist im 'fstab' mit 'sync' eingetragen. Die Durchschnittswerte nach mehreren Kopiervorgängen, mit einer 500MB Datei. cp-Terminal –- dient als Basis Vergleich Midnight Commander - MC –- ca.=0 Sekunden –- kein Unterschied Thunar –- ca.+22 Sekunden PCManFM / Nautilus / Caja –- ca.+22 Sekunden –- ähnlich schnell wie Thunar XFE –- ca.+70 Sekunden –- hat mich überrascht, extrem langsam
@Vegeta je nachdem wie mit Thunar kopiert wird (also ob die zu kopierende Datei sichtbar im Fenster ist oder z.B. in einem Ordner kopiert / verschoben wird, wo sie nicht zu sehen ist)
Daran dachte ich auch schon, bei 'Nautilus' sieht man den Kopiervorgang nicht, bzw es erscheint ein kleines Symbol in der oberen Leiste. Ist halt Ausgeblendet. Doch sind die Werte gleich wie bei Thunar.
Aber besonders fällt da 'XFE' auf, extrem langsam, konnte es kaum glauben, trotz mehrer Kopiervorgängen. 'tumblerd' hm, muss erst nachlesen was das ist. Ich werde es noch mit Xubuntu 16.04 und Debian 9.3 ausprobieren.
|
Vegeta
Anmeldungsdatum: 29. April 2006
Beiträge: 7943
|
picnerd schrieb: Wir reden ja jetzt nur vom Kopiervorgang. Beim verschieben muss zusätzlich ja noch die Quelle nachträglich gelöscht werden. Das würde zusätzlich Zeit benötigen und das von user_unknown angesprochene zerknüllen und in den Papierkorb werfen auslösen (auch wenn man es nicht sieht).
Wenn die Datei auf einer anderen Partition oder Laufwerk verschoben wird, wird sie kopiert und das Original gelöscht, ja. Ist die Partition allerdings gleich, dann passiert nichts weiter als dass die Datei dem neuen Zielordner zugeordnet wird. Dass das Löschen von Dateien allerdings signifikant den Kopiervorgang verlangsamen soll, wäre bei Multitasking und schnellen HDDs oder gar SSDs ein absolutes Armutszeugnis und eine eingeblendete Animation wie bei Windows, die es bei Xfce nicht mal gibt, sorgt ganz sicher nicht dafür dass der Kopiervorgang verlangsamt wird. Es sei denn die Animation müsste pro Datei einmal abgespielt werden und der eigentliche Kopiervorgang würde unterdessen angehalten.
|
picnerd
Anmeldungsdatum: 17. März 2016
Beiträge: 872
|
Vegeta schrieb: picnerd schrieb: Wir reden ja jetzt nur vom Kopiervorgang. Beim verschieben muss zusätzlich ja noch die Quelle nachträglich gelöscht werden. Das würde zusätzlich Zeit benötigen und das von user_unknown angesprochene zerknüllen und in den Papierkorb werfen auslösen (auch wenn man es nicht sieht).
Wenn die Datei auf einer anderen Partition oder Laufwerk verschoben wird, wird sie kopiert und das Original gelöscht, ja. Ist die Partition allerdings gleich, dann passiert nichts weiter als dass die Datei dem neuen Zielordner zugeordnet wird. Dass das Löschen von Dateien allerdings signifikant den Kopiervorgang verlangsamen soll, wäre bei Multitasking und schnellen HDDs oder gar SSDs ein absolutes Armutszeugnis und eine eingeblendete Animation wie bei Windows, die es bei Xfce nicht mal gibt, sorgt ganz sicher nicht dafür dass der Kopiervorgang verlangsamt wird. Es sei denn die Animation müsste pro Datei einmal abgespielt werden und der eigentliche Kopiervorgang würde unterdessen angehalten.
Ja, sehe ich genauso. 😉 sajder schrieb: Ich habe jetzt ein paar Dateimanager verglichen, alle unter Xubuntu 17.10 installiert. Der USB-Stick wie bereits erwähnt ist im 'fstab' mit 'sync' eingetragen. Die Durchschnittswerte nach mehreren Kopiervorgängen, mit einer 500MB Datei. cp-Terminal –- dient als Basis Vergleich Midnight Commander - MC –- ca.=0 Sekunden –- kein Unterschied Thunar –- ca.+22 Sekunden PCManFM / Nautilus / Caja –- ca.+22 Sekunden –- ähnlich schnell wie Thunar XFE –- ca.+70 Sekunden –- hat mich überrascht, extrem langsam
Eine Frage: Wie misst du die Zeit? Nur so als Info. Da Thunar genauso schnell wie andere Dateimanager ist spricht für ihn als Standarddateimanager in XFCE. Das jetzt ausgerechnet XFE so abloost wundert mich aber ich muss sagen das ich mich mit diesem noch nie beschäftigt hatte. Das MC als Terminal-Dateimanager keinen unterschied zeigt bringt mich auf den Gedanken das Problem beim programmieren eines Grafischen-Dateimanagers zu suchen. Da mir aber die Programmierkentnisse fehlen kann ich da nichts zu beitragen. user_unknown hat da ja tiefer gehende Kenntnisse glaube ich. Ich könnte mir vorstellen, da ja (und da müsste ich evt. meine Meinung doch ändern) Prozesse der Reihe nach angestoßen werden vom Programm (Dateimanager), einfach das Naderör im zusätzlichen Code zum Grafischen Anzeigen zu suchen ist. Der zusätzliche Code verlangsamt dann halt die gesammte Aufgabe. Ob man da mit verschiedenen Programiersprachen auch noch einen Zeitunterschied feststellen kann? mfg
|
Vegeta
Anmeldungsdatum: 29. April 2006
Beiträge: 7943
|
picnerd schrieb: Ich könnte mir vorstellen, da ja (und da müsste ich evt. meine Meinung doch ändern) Prozesse der Reihe nach angestoßen werden vom Programm (Dateimanager), einfach das Naderör im zusätzlichen Code zum Grafischen Anzeigen zu suchen ist. Der zusätzliche Code verlangsamt dann halt die gesammte Aufgabe.
Ein Programm arbeitet die Programmabläufe nacheinander ab, da es zwischen den Abläufen aber normalerweise viel Zeit hat, sieht es aus als würde das alles gleichzeitig geschehen. Wenn nun aber ein arbeitsintensiver Schritt läuft wie das Kopieren großer Dateien oder eine Endlosschleife, dann ist das Programm voll und ganz mit sich selbst beschäftigt und die GUI friert ein - hat sicherlich jeder schon mal erlebt.
Bei Qt kann man sich da mittels processEvents behelfen, wo man die GUI manuell updaten kann und sie friert nicht ein. Besser ist es natürlich einen arbeitsintensiven Schritt in einen eigenen Thread auszulagern, der dann ganz unabhängig vom Hauptprogramm die Berechnung durchführt. Die GUI kann jedenfalls nicht für einen Zeitverlust von fast einer halben Minute verantwortlich sein, die GUI wird innerhalb von maximal weniger Millisekunden aktualisiert. Ich tippe wie gesagt auf tumblerd. Man könnte ja auch mal einen Test machen, dass man mit cp kopiert. Dann aber den Ordner, wo die Datei hinkopiert wird, mit Thunar vorher öffnet, ob es dann ebenfalls zu einer Verlangsamung kommt.
|
sajder
(Themenstarter)
Anmeldungsdatum: 1. März 2017
Beiträge: 19
|
Ich hab das Ganze noch mit "Debian 9.3.0 Xfce4" verglichen, die Werte sind identisch. picnerd Eine Frage: Wie misst du die Zeit? Nur so als Info.
Für 'cp' hab ich 'time' genommen.
Und bei den Grafischen Dateimanager hab ich eine Stoppuhr benutzt. Vegeta Ich tippe wie gesagt auf tumblerd.
Ich hab jetzt 'tumblerd' deinstalliert. Auf den Kopiervorgang hat es keinen Einfluss, die Werte sind gleich. Aber dafür ist der RAM verbrauch niedriger, das freut mich trotzdem.
Man könnte ja auch mal einen Test machen, dass man mit cp kopiert. Dann aber den Ordner, wo die Datei hinkopiert wird, mit Thunar vorher öffnet, ob es dann ebenfalls zu einer Verlangsamung kommt.
Nein, kein unterschied. Außer das man der Datei zuschaut, wie die MB Werte ansteigen 😉. Interessant wird es, wenn es um einen Ordner mit mehreren Dateien geht, hier ein Beispiel: 500MB Ordner, Inhalt 107 Dateien 'cp'-Terminal benötigt ca. 104 Sek. Thunar benötigt ca. 162 Sek. (58 Sekunden länger)
2 GB Ordner, Inhalt 444 Dateien 'cp'-Terminal benötigt ca. 7 Min. Thunar benötigt ca. 12 Min. (5 Minuten länger)
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
Vegeta schrieb: sajder schrieb: Wieso ist Thunar beim kopieren von Daten auf ein USB-Stick langsamer im vergleich zu 'cp' per Terminal?
Ich denke das lässt sich relativ leicht erklären, je nachdem wie mit Thunar kopiert wird (also ob die zu kopierende Datei sichtbar im Fenster ist oder z.B. in einem Ordner kopiert / verschoben wird, wo sie nicht zu sehen ist) passieren da mehrere Dinge im Hintergrund. Ich habe bei größeren Dateien schon öfter beobachtet, dass während des Kopiervorgangs das Thumbnail der Datei aktualisiert wurde.
Es gibt eigentlich keinen Anlass dafür. Das Verschieben oder Kopieren einer Datei dürfte ja dessen Thumbnnnail nicht ändern. Man kann den Thumbnail ja mitkopieren. Außer dieser tumbler ist tumb und kriegt gar nicht mit, was läuft, nur wo Dateien auftauchen und arbeitet dann los.
Wenn dies generell bei allen Dateien gemacht wird, dass da tumblerd während des Kopierens die Daten analysiert, würde dies bei einem so langsamen Medium wie einem USB-Stick diese zusätzliche Verzögerung schon erklären können.
Wenn er einfach dazwischen hängen würde, nicht. Die Datei ist ja schon gelesen worden und muss sowieso geschrieben werden - die Analyse für ein Thumbnail könnte also in RAM und CPU stattfinden ohne Quell- und Zielmedium ein 2. Mal zu bemühen. Aber womöglich ist es schlecht implementiert. Man kann auch in Thunar /usr/bin öffnen und staunen, wie lange es dauert erstmalig die 2000 Dateien zu parsen, nur um 25 davon anzuzeigen (begrenzte Fenstergröße). Pro Bootvorgang kann man das zwar nur 1x beobachten, weil die Ergebnisse dann gecached werden, aber trotzdem völlig unverständlich. MC < 1s. Dazu kommt, dass das Programmicon in den 2000 Fällen identisch ist, das sind nicht etwa 2000 verschiedene! Einen größeren Schrott hat die Welt noch nicht gesehen, allerdings einen gleich großen, den Dateimanager unter Windows, der macht das ähnlich. So kam ich drauf, als ich Häme und Spott über diesen kippen wollte, und unter Linux nachsah, wie es hier aussieht, um feststellen zu müssen: Nicht besser. 😉 Gerade noch mal überprüft. Hey, das ist inzwischen gefixt! Ich hatte einen Bug/Feature-Request offen seit 2008 oder so, und nur alle 2 Jahre geschaut, ob es unverändert ist. ☺
|