Date: prev next · Thread: first prev next last
2025 Archives by date, by thread · List index


html,body{background-color:#fff;color:#333;line-height:1.4;font-family:arial, helvetica, 
sans-serif;;}
Hallo Michael


Mit den vielen Dateien in der komplexen Ordnerstruktur, das möchte ich nur bestätigen. Ich vermute 
allerdings, dass nicht die wirkliche Prozessorarbeit die Zeit benötigt, sondern hier auch das 
Response im Filesystem, das geht halt durch mehrere Ebenen. Wenn ich meine Javadoc-Dokumentation 
auf meinen Webserver per Einzelfile übertrage, katastrophal lange. Daher zippe ich die files, 
schicke den zipfile rüber und rufe beim Server Unzip auf. Letzteres geht rasend schnell (Auspacken 
dieser vielen Files). D.h. auch hier ist Request und Response bei jedem File übers Internet der 
Zeitfresser, und nicht die Datenmenge an sich (das Zippen ist ca. die Hälfte der MByte, das ist es 
nicht). Und: viele Files schreiben auf dem Server selbst geht sehr schnell, Files schreiben über 
Netzwerkschnittstelle (dürfte auch bei lokaler Kommunikation, Samba, so sein) dauert oft viel 
länger.


Also mein Hinweis ist: Das ist nicht die Datenmenge, sondern die Kommunikation die zum Hängen 
führt. Und das war auch die Hauptaussage im Thread, der hier fehlt, mit dem Kollegen mit dem 
Arabischen Zeichensatz. 


Mein Wissen ist freilich auch nicht universal, aber wenn ich in den odt-zip reinschaue, dann ist 
das eine recht flache Struktur. Sind viele Bilder drin, dann sind das zwar viele Bilddateien, aber 
so viele nun auch nicht. Ich müsste, um genaue Aussagen zu treffen, Rechenzeitmessungen mit 
Beispielen machen. Habe aber dafür nicht die Zeit.


Ich habe noch eine andere Erfahrung: Ein Dokument.odt mit ca. nur 100 Seiten hat immer länger 
gebraucht bei "Update all" Minuten! Das lag an einer komplex in der Zeit gewachsenen Struktur von 
(unnötigen) direkten Styles im content.xml. Ich habe im XML-File aufgeräumt, generiere den immer 
mal neu. Seit dem dauert das bei nunmehr 135 Seiten nur wenige sekunden, wie es sein soll. Manchmal 
gibt es da komplexe Ursachen, denen wir aber nachgehen müssen.




Michael Höhne schrieb am 17.06.2025 21:21 (GMT +02:00):
Hallo Hartmut,


Am Dienstag, dem 17.06.2025 um 15:24 +0200 schrieb 9876@vishia.de:




Entpacken geht heutzutage eigentlich auch sehr schnell. Ich arbeite
manchmal umfangreichere Zipfiles durch mit Suchen, Vergleichen, das
ist immer nur eine Sekundenaktion. 


Ich sage mal: Jein!


Das kommt darauf an, wie viele einzelne Dateien gepackt oder entpackt
werden müssen.


Ich habe das gerade einmal getestet: Ich habe 500000 kleine Dateien in
einer Ordnerstruktur mit 500 Ordnern in drei Ebenen verteilt. Insgesamt
sind das 500 MB blanker Text.


Das zweite Testobjekt ist eine Textdatei mit einer Größe von 500 MB.


Packe ich die Ordnerstruktur, so braucht das Zip-Programm 40 Sekunden.
Für die gleich große Textdatei "nur" 36 Sekunden.


Aber jetzt kommt es: Zum Auspacken der Textdatei braucht es 3 Sekunden,
zum Auspacken der Ordnerstruktur aber 38 Sekunden. Das liegt daran, dass
das Entpacken zwar sehr flott geht, aber das Anlegen der Datei im
Dateisystem bremst bei so vielen Dateien einfach enorm aus. Und das war
jetzt auf einer SSD, wo der Zugriff auf einen Block durch keine
Kopfbewegung gebremst wird.


Das kann man auch beim Kopieren sehen, insbesondere auf eine
Netzfreigabe:


Die 500MB große Datei benötigt 10 Sekunden, wenn ich sie zu meiner NAS
kopiere. Die Ordnerstruktur mit den 500000 kleinen Dateien hingegen
stolze 1,5 Stunden. Durch die Verwaltungsarbeiten (anlegen, öffnen,
schließen von Dateien) wird so viel Zeit vertrödelt, dass die eigentlich
Datenübertragung kaum noch ins Gewicht fällt.


Wenn ich also eine .odt-Datei öffne, die aus vielen kleinen Objekten
besteht, kann das verdammt lange dauern. Eine gleich große Datei, die
wenige Objekte enthält, lädt dagegen dann sehr flott.


Gruß,
Michael




-- 
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme?https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/Tipps zu 
Listenmails:https://wiki.documentfoundation.org/Netiquette/deListenarchiv:https://listarchives.libreoffice.org/de/users/Datenschutzerklärung:https://www.documentfoundation.org/privacy
-- 
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.