Guten Tag,
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.
Es führt jetzt zwar vom eigentlichen Thema weg, aber ich habe dazu trotzdem
zwei kurze Fragen:
1. Wo gibt es dieses "Update all"?
2. Wie kann man diese "content.xml" einfach neu generieren?
Danke im Voeaus für die Antworten.
Gruß IB
-------
Am 17.06.25 um 22:52 schrieb [email protected]:
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.
--
Liste abmelden mit E-Mail an: [email protected]
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
