Hohe CPU-Belastung durch grosses Dokument mit vielen Grafiken

[snoopy78]

Hallo zusammen

Ich erstelle ein Dokument zum Thema Assembler (knapp 400 Seiten). Es enthält mehrere Bilder (max. 500 kB pro Bild im Speicher) und dazu diverse Formelobjekte und Zeichnungen, welche ich im Draw erstellt und gruppiert habe.
Im Speicher belegt das Dokument rund 3.5GB Speicher. Problematisch ist einfach, dass die CPU mit 17-20% CPU-Last läuft und entsprechend die Lüfter rauschen. Dies startet direkt nach dem Öffnen des Dkumentes. Ich vermute, dass dann ein Layout-Assistent startet, welcher das Dokument aufbereitet. Leider bleibt die CPU-Last bestehen, auch wenn das Dokument schon länger offen ist und nicht damit gearbeitet wird.
Manchmal ist es auch so, dass die OLE-Grafike von Draw nicht angezeigt werden (man muss etwas scrollen, dann werden sie wieder angezeigt).
Das Verhalten ist gleich, auch wenn ich im abgesicherten Modus von LO über die Konsole starte.
Nun wollte ich fragen, ob es eine Möglichkeit gibt, die Ursache einzugrenzen, da alles über einen Prozess (soffice.bin) läuft. Kann man in einer Umgebung wie VisualStudio einen Trapprozess starten, welcher zum Beispiel aufzeichnet, welche Routinen wie viel Mal durchlaufen werden. Evtl. könnte man so einfach einkreisen, wo der Prozess unnötig Ressourcen verbratet. Dadurch, dass er ja das Layout nicht ständig anpassen muss, vermute ich, dass er irgendwo unnötig Kreise zieht, was man aber bei kleinen Dokumenten nicht bemerkt.
Evtl. gibt es auch einen Guide, wie man die Sourcen mit Debugsymbolen kompilieren kann und dann mittels Merkern die Aufrufe zählt. Zugriff auf Linux und Windows habe ich entsprechend, doch wenig Erfahrung mit solchen grossen Software-Projekten.

Gruss aus der Schweiz, Markus Grob

[miesepeter]

Hallo,

• du hast hoffentlich im nativen Dateiformat (odt) gespeichert und nicht z. B. im docx-Format. Dies würde vielfältige Konvertierungen auslösen.
• Bilder im Dokument verlinkt man am besten; dadurch bleiben die Dateien schlank.
• OLE-Objekte können zu instabilem Verhalten führen (siehe auch deine Ausführungen) und ich würde diese auch weitgehend vermeiden.
• Wenn du deinen Text vorwiegend hart formatiert hast und die Zeichen- und. Absatzvorlagen kaum nutzt, dann kann das auch zu empfindlichen Störungen der Stabilität eines Writer-Dokuments führen. Eine Folge der manuellen Formatierung ist u. a. das Anwachsen und eine große Unübersichtlichkeit im "Quelltext" der Textdateien...

Im Übrigen kann man halt ohne die Datei nicht viele Ursachen begrenzende Ausführungen machen... - Ciao und viel Erfolg!

EDIT
Bei den genannten Prozessen zur Nachverfolgung von (internen, programmspezifischen) Verarbeitungsroutinen kenne ich mich nicht aus, ich wüsste auch nicht, wie man diese Prozesse initiiert und auswertet.

[juribel]

Moin,

ich kann mich nur den Ausführungen von miesepeter anschliessen, Ähnliches beobachte ich auch. Eingebettete Bilder fressen viel Performance, besonders beim Blättern, und erst recht Bilder, die nicht extern zugeschnitten und skaliert wurden, sondern innerhalb LibreOffice. Viele Tabellen sind ebenfalls nicht förderlich. Mit OLE habe ich selber keine Erfahrung, würde das aber ebenfalls als Hauptursache ausmachen.

Die Bilder zu verlinken könnte eine gute Lösung sein, aber ich sehe darin den Nachteil, dass dann zum Versenden viele Dateien eingepackt werden müssen anstatt nur einer einzigen.

Individuelle Formatierungen (Zeichen, Absätze) sind nach meiner Erfahrung ebenfalls gar nicht gut, auch wenn dies in der grafischen Oberfläche von LO prominierend und dominierend angeboten wird. "Richtigerweise" arbeitet man mit Absatz- und Zeichenformaten, das ist im Endeffekt das Bequemste.

[Pit Zyclade]

...
Individuelle Formatierungen (Zeichen, Absätze) sind nach meiner Erfahrung ebenfalls gar nicht gut, auch wenn dies in der grafischen Oberfläche von LO prominierend und dominierend angeboten wird. "Richtigerweise" arbeitet man mit Absatz- und Zeichenformaten, das ist im Endeffekt das Bequemste.

Das mag zwar stimmen, nur ist der Text unklar formuliert.
Man soll nicht mit "individuellen" (direkt formatierten?) Absatz- und Zeichenformaten arbeiten sondern mit vorhandenen (?) oder mit persönlichen?
Ist das so gemeint? Man kann vieles beschreiben, nur muß es der Empfänger verstehen können.

[juribel]

Damit habe ich gemeint, Zeichen und Absätze nicht oder nur ausnahmsweise "direkt" zu formatieren, sondern Vorlagen zu verwenden, gleich ob vorhandene oder selbst erstellte. Es ist ja kinderleicht, eigene Vorlagen zu erstellen und diese mit Formatvorlagen → Vorlagen verwalten (Taste F11) anzusehen, auszuwählen, zu ändern usw.

Auch aus "direkt" formatierten Zeichen oder Absätzen kann man neue Zeichen- und Absatzvorlagen erstellen.

Ich hoffe, dies kommt jetzt ein bisschen klarer an

[snoopy78]

Hallo miteinander

Danke für die Tipps und hier entsprechend eine Zusammensetzung der Punkte:

• Bin schon seit Staroffice dabei und entsprechend ist odt eingestellt.
• Ich habe rund ein Dutzend Bilder drin und alle sind extern zusammengeschrumpft worden und belegen einzeln nicht mehr als 500kB im Speicher und dürfen daher auch nicht die Ursache des Problems darstellen, da selbst meine Matrox 4GB dedizierten Speicher hat und das Dokument rund 3GB gross ist.
• Was ist das Problem bei OLE-Objekten? Ich erstelle diese als Zeichnungen im Draw und daher sollten diese ja einfach eingebunden werden oder frisst das zu viele Ressourcen? Falls ja, wo könnte mir jemand Antworten liefern? Da ich auch diverse Formeln einbinde, welche ebenfalls OLE-Objekte sind, stellt sich die Frage, ob LO hier ein prinzipielles Performance-Problem hat und wer hier Abhilfe schaffen könnte? Ich könnte mir vorstellen, dass die Objekte für die Ansicht einfach in Grafiken konvertiert werden und erst beim Bearbeiten wird auf das dahinter liegende Objekt zugegriffen. Das braucht nur eine einmalige Arbeit beim Einbinden (Man könnte etwa auch nach dem System "copy on write", beim Einbinden das Objekt konvertieren in eine Grafik und beide Objekte hinterlegen und für die Anzeige nur das Grafikobjekt laden solange es nicht bearbeitet werden soll).
• Hart formatieren? Danke für den Hinweis, doch ich habe noch einen Bug offen, dass LO standardmässig das Default umstellen sollte auf Fliesstext, weil sonst jeder ohne Hintergrundkenntnisse mit Default arbeitet. Entsprechend verwende ich nur eigene Formatvorlagen und keine direkte Formatierung.
• Wenn es um die Datei geht: https://dict.ch/allgemein/
• In Bezug auf Tabellen habe ich über 60 Stück im Dokument und ich erwarte eigentlich, dass dies keinen grossen Einfluss auf die Performance haben sollte.

Weiss sonst jemand, auf wechem Kanal man die Entwickler am besten erreicht, um über das Thema zu diskutieren? Ich würde ja gerne selbst Analysen vornehmen, doch bräuchte ich da Hilfe von Leuten, die Wissen, wo es sich lohnt.

[miesepeter]

Weiss sonst jemand, auf wechem Kanal man die Entwickler am besten erreicht, um über das Thema zu diskutieren? Ich würde ja gerne selbst Analysen vornehmen, doch bräuchte ich da Hilfe von Leuten, die Wissen, wo es sich lohnt.

Hallo,

vermutlich können dir aktive Beiträge in Mailinglisten weiterhelfen: https://de.libreoffice.org/get-help/mailing-lists/

Du könntest dich auch an folgende Entwicklerin wenden:
https://ask.libreoffice.org/
Melde dich dort an.
Schreibe an Regina (und bitte sie um Hilfe): https://ask.libreoffice.org/u/regina/summary

Viel Erfolg dabei!

EDIT1
Ab ca. Version 7.6.x kann man im Vorlagenmanager (F11) auch die direkte Formatierung von Absätzen und Zeichen anzeigen lassen...
Mir fiel Folgendes bei deinem Buch auf:

• Zeichen in Tabellen waren hart formatiert. Bei vielen Tabellen: Vielleicht ein Problem?
• Vorlagen bei Überschrift 1 und Fußzeilen (Ausrichtung manuell geändert) zeigen auch Schraffuren, die auf direkte Formatierung hindeuten.
• Z.B. S. 27 für mich unbekannte Erscheinung von "Code im Text" (vielleicht kannst du es mir erklären) - siehe Screenshot:

  

  CodeImText.png (19.9 KiB) 1870 mal betrachtet

• Ansonsten finde ich, dass dein Buch sehr gut strukturiert ist und viele Elemente eines vorbildlichen Aufbaus enthält.

EDIT2

DIHO.png (28.38 KiB) 1856 mal betrachtet

DIHO = Despair Index due to the Handling of Objects
Gefunden hier:
To Tame a Writer (2018), Ricardo Gabriel Berlasso, S. 13
Download aus: https://frommindtotype.wordpress.com/ - z. Z. nicht erhältlich, neue Auflage erste Hälfte 2024 erwartet

[musikai]

Hier in LO 7.4.6.2 auf Windows 10 ist die CPU Leistung nur am Anfang bei 30%.
Nachdem die Seiten durchgezählt sind beruhigt sich alles und ist bei 0-1% im Ruhezustand.

Dein Dokument (ca. 3,8 mb) belegt ca 210 mb im Speicher.
Alles läßt sich flüssig bearbeiten.

Es ist nicht mal nötig, die Anzeige der Bilder und Grafiken abzustellen (Ansicht->Bilder und Diagramme), was sonst ja manchmal hilfreich sein kann.

[juribel]

Dein Buch, das du zum Download verlinkt hast: Ist es das gesamte Buch? Bei mir zeigen sich mit LibreOffice 7.4.7.1 unter debian 12 damit jedenfalls keinerlei Auffälligkeiten. Keine CPU-Last oder sonstige Probleme.

Der Speicherbedarf des LibreOffice-Prozesses liegt hier bei ca. 370 MB.

@miesepeter: "Code im Text" ist eine Zeichenvorlage.

Hochinteressantes Buch, übrigens

[juribel]

Noch zwei Anmerkungen:

1. Ich war ein grosser Fan des 6502 Prozessors, den habe ich damals tatsächlich in Assembler programmiert. Demzufolge vermisse ich natürlich ein entsprechendes Kapitel in deinem Buch Damals hatte ich mir einen Computer mit diesem Prozessor gebaut, in Anlehnung an den "Junior Computer" der Zeitschrift "elektor".

2. Ich sehe mit Bestürzung, wie viel ich über LibreOffice und auch über Assembler noch nicht weiss