[de-users] Re: A: [de-users] Ladezeiten – "Update all", "content.xml"

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 9876@vishia.de:
> 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: 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