PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie formulieren? Immer längere Speicherzeiten mit neueren BS



juvoaa
21.01.11, 17:50
Hallo, folgendes Problem:

Ich habe einen Ordner mit ca. 5000 Bildern. Wenn ich nach Anwendung von Gimp oder aus
eine Seite speichere dauert es sehr lange.
Das unter debian Lenny.
Debian etch ist schneller und
Suse 9.3 ist am schnellsten. Normal zügig.

Ich verstehe nicht, wieso die neueren Betriebssysteme immer langsamer sein sollen.
Vor allem, da Gimp nicht mehr bietet als früher.

Kann ich an irgendwelchen Einstellungen was ändern?

Danke und Gruss juvo

oziris
21.01.11, 21:40
Meinst Du, wenn Du im GUI eine Datei dazu speicherst, dann dauert es, bis der Speichern-Dialog vollständig geladen ist bzw. wieder verschwunden ist?

ThorstenHirsch
21.01.11, 22:52
Vielleicht die Anzeige im Datei-Öffnen/Speichern-Dialog...?

kreol
21.01.11, 23:03
Setz doch mal einen simplen Benchmark mit "time cp ...".

Und welche FS bei den verschiedenen OS sind beteiligt? Das kann (gerade bei vielen kleinen Dateien) schon etwas ausmachen.


Kreol

undefined
22.01.11, 11:08
File System, Lese die mount Dokumentation zu "noatime,nodiratime" und "data=writeback" für dein ext* Filesystem.

juvoaa
22.01.11, 11:41
Meinst Du, wenn Du im GUI eine Datei dazu speicherst, dann dauert es, bis der Speichern-Dialog vollständig geladen ist bzw. wieder verschwunden ist?

Genau das ist es.
FS ist ext3; den Rest kann ich erst nachher ausprobieren.
Danke schonmal!

oziris
22.01.11, 13:39
Genau das ist es.
Das liegt, meiner Erfahrung nach, nicht am Linux (Kernel) und auch nicht am Dateisystem, sondern am GUI Toolkit. Der einzige mir bekannte Workaround ist, Unterverzeichnisse anzulegen, damit nicht so viele Dateien in einem Verzeichnis sind.

PS: Es könnte evtl. schneller gehen, wenn als Toolkit etwas flüssigeres, z.B. Xaw(3D) oder GNUstep, benutzt würde, aber darauf hat man als Anwender keinen Einfluss und die Bedienung dieser Toolkits ist auch sehr unterschiedlich. Es dauert eben einfach 5000 kleine Icons mit Texten daneben, zur Anzeige vorzubereiten und es scheint mir auch, dass die Prüfung, ob ein Dateiname bereits vorhanden ist, der überschrieben werden könnte, in einigen Toolkits nicht besonders effizient gelöst wurde...

jeebee
22.01.11, 22:30
Eine Möglichkeit wäre, die Thumbnail-Funktion (im Nautilus unter Bearbeiten > Einstellungen > Vorschau > Miniatur-Vorschaubilder anzeigen auf Nie setzen) von Nautilus und dem Datei-Speichern Dialog abzuschalten...

oziris
23.01.11, 14:42
Bei mir sind da keine Bildchen (ich hab auch keinen Nautilus) und trotzdem habe ich das "Problem" auch.
... ist aber auch egal, vielleicht hilft es ja bei juvoaa.

kreol
23.01.11, 19:24
Schon witzig: Ohne jede Info durch den TE (ausser Deb und SuSE aus #1) landet man bei ext* und Nautilus.

ext3 (bei allen beteiligten OS?) wurde ja nun bestätigt, der Rest ist, zumindest für mich, noch im Nebel. Oder habe ich was überlesen?

Kurz: Bevor wir hier wild rumraten wäre es wohl effektiver, wenn der TE mal Info liefert.

Falls es an der GUI liegen sollte wäre es ja schon hilfreich zu wissen, welcher WM in welcher Version am Start ist. Versionen der Apps wären hilfreich und was macht was genau. Etc. pp.


Kreol

juvoaa
24.01.11, 11:21
WM soll vermutlich windowmanager sein: gnome ! version 1:2.22.2~5 - wenn ich das aus dem synaptic richtig verstehe.
In der suse 9.3 läuft kde (vers weiß ich gerade nicht, da ich im lenny bin; ist das kriegsentscheidend?)
Welche infos sind ansonsten noch von Interesse?
Was mich zu der Fage veranlasst hat ist, dass die neueren Systeme langsamer sind.
Der alte Gimp ruft auch nicht die Liste aller Dateien des Ordners beim Speichern auf. Wenn ich da im Gimp 2.4.7 etwas "abstellen" könnte?

oziris
24.01.11, 21:26
Was mich zu der Fage veranlasst hat ist, dass die neueren Systeme langsamer sind.Das ist nicht ungewöhnlich, das bei neuen Versionen i.d.R. neue Features und grafische Spielereien hinzugefügt werden. Die meisten Heimanwender wollen das ja auch und kaufen daher gern neue Hardware. Nur möchten die Benutzer nicht gleich überfordert werden: Es darf ruhig etwas schnörkeliger sein, aber die gewohnten Knöpfchen sollten nicht zu weit von der gewohnten Stelle entfernt sein, weil sonst gibt's Rebellion und Fork und Verödung usw..

Ich denke man kann einen gewissen Zynismus erkennen. Ich persönlich hätte es nämlich gern, wenn Toolkits eine Art Policy hätten, in der z.B. drin steht: "Wir machen nur Features rein, die die Geschwindigkeit bei diesem und jenem Benchmark nicht beeinträchtigen und außerdem optimieren wir immer auf RAM" oder sowas. Weil zu viele Köche verderben den Brei, es sei denn, es ist genau vorgeschrieben was reinkommt, dann isses egal, wie viele da mitmischen.