Hohe CPU-Last bei Writer-Dokument

Deutsch
, ,
#1

Hi zusammen,

seit kurzem habe ich ein Problem mit ein paar Writer-Dokumenten. Die Bearbeitung in den Dokumenten erzeugt eine extrem hohe CPU-Last bei der Eingabe von Text, teilweise dauert es 2 Sekunden nach einem Tastendruck, bis der Buchstabe auf dem Bildschirm erscheint, wenn ich ganze Wörter tippe auch gerne mal 5 Sekunden. Andere Writer-Dokumente oder Tabellen sind davon offensichtlich nicht betroffen, hier funktioniert alles wie gehabt flüssig. Die Dokumente sind alle 3 Seiten lang mit einem Photo und zwei Spalten, sonst keine besonderen Formatierungen.

Ich nutze Version 7.0.2. auf Linux, auf Windows tritt das Problem aber auch auf. Es scheint an den Dokumenten zu liegen. Alle Dokumente sind Kopien von einander und bis vor ein paar Tagen funktionierte noch alles gut.

Gibt es die Möglichkeit, die Dokumente zu checken und ggf. zu reparieren? Oder ist das evtl. ein bekannter Fehler in der aktuellen Version?

Danke, steffen

EDIT_ebot aus Antwort entnommen, Antwort gelöscht:

Ergänzung: Wenn ich das Bild aus dem Dokument lösche, ist das Problem gelöst. Auf den Seiten, auf denen das Bild sich nicht befindet, tritt das Problem auch nicht auf. Wenn ich das Bild wieder in das Dokument kopiere ist das Problem zurück.

Es scheint aber nicht an dem Bild zu liegen, auch wenn ich andere Bilder in das Dokument kopiere tritt das Problem auf.

#2

Welches Dokumenten-Format verwendest Du - das native LibreOffice Format ODF (i.e. .odt im Falle von Writer) oder eine anderes (.doc(x))? Sind die problematischen Dokumente zwischen verschiedenen Formaten hin und her gespeichert worden?


> Alle Dokumente sind Kopien von einander

Was heißt hier “Alle” - “Alle”, die das Problem haben oder “Alle”, auch die, die kein Performance-Problem zeigen?

#3

Ich verwende nur ODT, keine anderen Formate. “Alle” in den Zusammenhang heisst, dass die Dokumente, die das Problem aufweisen, Kopien voneinander sind. Andere Dokumente, die nicht zu der Gruppe von Kopien gehören, weisen das Problem nicht auf.

#4

Klingt ein wenig wie dieser Bug hier #tdf137456

#5

Wenn das mit dem Bild zusammenhängt: Hast Du einmal ausprobiert, ob daran sich etwas ändert, wenn Du die Verankerung änderst (am Absatz, am Zeichen, als Zeichen …)?

#6

Nein, eine Veränderung der Verankerung macht keinen Unterschied.

#7

Hallo,

aus meine Sicht und Erfahrung ist das Bild eindeutig im Format und in der Auflösung zu groß.
Mit einem Bildbearbeitungsprogramm lassen sich die Bildinformationen leicht auslesen.
Hier mal eine mit GIMP ausgelesen Bildinformation:
Gimp Bildinformationen.png

Dieses Bild habe ich vor einiger Zeit aus einer Writer-Datei extrahiert und untersucht,
eben weil die Datei sehr lange zum Laden und bearbeiten brauchte.
Es war übrigens nicht das einzige BIld in diesem Dokument, welches viel zu groß war.

Druckgröße: ca. 4 Meter x 50cm!!!

Betrachte GENAU die einzelnen Bild-Informationen des Screenshots.
Besonders das Format und der beanspruchte Arbeitsspeicher nach dem Laden des Bildes.
Aus ca. 560kB (im gepackten Zustand) werden ca. 480 MB im RAM!!!

Ich fand in der Datei auch ein Bild, welches ca.800kB (im gepackten Zustand) und im RAM wurden daraus ca.2,0GB!!!
Das ist kein Einzelfall!

Wie geschieht so etwas?

Der Anwender scannt ein BIld in einem riesigen Format (3-4Meter Breite) und einer enormen Auflösung. Dann fügt er dieses Monsterbild in eine DINA4-Seite ein und schrumpft es mit der Maus auf eine Breite von 20cm.
Ist das Bild kleiner geworden?
NEIN, es ist nur zusammengequetscht.
Speichern und neuladen, plötzlich hohe CPU-Last usw.
Wenn dann noch eine lahme GPU und wenig Grafikarten-RAM, zusätzlich wenig Speicherplatz auf der Festplatte,
ggf. eine etwas lahme CPU und wenig RAM hinzukommt ist die Katastrophe perfekt!

Fazit:
Öffne Dein/e Bild/er mit GIMP oder Irfanview, etc. lese die Bildinformationen Deines Bildes aus.
Verkleinere das Format des Bildes und die Auflösung, dann sollte es laufen.
Zumindest wenn Deine Hardware OK ist.
Auch die Auslagerungsdatei, bzw. Swap-Datei sollte über ausreichend Speicherplatz verfügen.
Unter Windows die Auslagerungsdatei auf jeden Fall von Windows automatisch verwalten lassen!
Es kusieren hier immernoch falsche Tipps aus längst vergangegen Zeiten.

Viel Erfolg, mit kleineren Bildern…

Gruß

Craig

#8

Danke für den Hinweis, aber so groß ist das Bild nicht. Laut Gimp sind das 150MB, wenn ich das Dokument in Libreoffice und das Bild in Gimp offen habe, sind noch mehr als 12 GB Arbeitsspeicher frei. Ausserdem habe ich an dem Bild genau gar nichts verändert und vor ein paar Tagen gab es das Problem noch nicht. Das einzige, was sich verändert hat, ist eine neuere Version von libreoffice (7.0.2 statt 7.0.1). Das scheint das Problem zu sein.

#9

Hallo Steffen,

verkleinere das Bild in GIMP, max. Format so groß wie Du es in der Datei brauchst, ggf. etwas kleiner und Auflösung, so das es beim Ausdruck nicht verpixelt ist.
Jedes MB zählt bei der Geschwindigkeit.

Ich persönlich finde ein Bild mit 150MB immer noch zu groß für Office-Dateien.
Gepackt < 150kB
Entpackt max. 2 MB

  1. Verkleinere Format und Auflösung des Bildes
  2. Erstelle ein neues Dokument
  3. Füge das neue Bild ein
  4. Speichern und schließen
  5. Erneut öffnen und testen.
  6. Wenn OK, dann die Daten Deiner Ursprungsdatei hineinkopieren.
  7. Speichern und testen
  8. Dokument schließen, öffnen und erneut testen.

Was passiert? Ist die Performance besser geworden?

Ich habe/ hatte mit den genannten Office Releases keine Probleme. Alles super scchnell.

good luck… :slight_smile:

#10

Was mich stutzig macht ist, dass die Probleme bei MadEagle mit den Vorversionen und gleichem Material nicht auftauchten.

Natürlich kann ein Dokument optimiert werden, aber wenn das bei “normalem” Nutzerverhalten unbedienbar wird (oder, wie in anderen Meldungen bei Bugs zu 7.0, abstürzt), dann ist da irgendetwas faul. Ich würde das Ganze als Film aufzeichnen und an eine Bugbeschreibung anhängen.

#11

Hallo Robert,

ich gebe Dir in allen Punkten recht.

In Sachen Fehleranalyse auf meinem System, packe ich mich immer zuerst an meine eigene Nase. Soll heißen, erst schrittweise den Fehler bei mir und auf meinem System, etc. suchen.

Deshalb meine Liste im letzten Kommentar und die Frage “Was passiert?”

Ich erwarte darauf eine Antwort:

  1. Wenn positiv, dann ist der Fehler gefunden :slight_smile:
  2. Wenn negativ, dann bleibt nur ein Bugreport :frowning:

Alle anderen Fehlerquellen wurden ja schon überprüft und ausgeschlossen.

Folgendes gehört nicht zwingend in diesen Post:

Ich selbst habe auch schon den ein oder anderen Fehler gemeldet, dass Ergebnis ist aus meiner Sicht eher etwas traurig. Wie Du bereits vor kurzem in der Maillingliste angemerkt hast: >>>Es muss klar werden, dass der Bug von allgemeinem Interesse ist…<<<

Deshalb eine kurze Frage an Dich:

Wie teile in Bugzilla mit, dass ich ebenfalls ein großes Interesse an der Behebung eines Bugs habe?

#12

Ich habe gemäss des Kommentars von Craig22 das Bild mit Gimp verkleinert, ein neues Dokument angelegt und getestet - alles gut. Wenn ich im Originaldokument das grosse Bild gegen das verkleinerte austausche funktioniert ebenfalls alles wie erwartet. Wie schon vermutet liegt es an der Grösse des Bildes.

Bleiben nur zwei Fragen:

  • Warum ist der Fehler bis vor ein paar Tagen nicht aufgetreten?
  • Warum macht ein “zu grosses” Bild Writer Probleme?

Man kann sicherlich argumentieren, dass Writer keine Bildbearbeitungssoftware ist und dass es der “richtige” Weg sei, das Bild erst extern zu verkleinern und dann in Writer einzufügen, aber ich denke, dass das Programm in der dieser Version das handhaben könnte (und in der Vergangenheit ja auch hat).

#13

Wenn Du eine Beispieldatei irgendwo hoch laden kannst, bei der das Problem für Dich aufritt, dann wäre das sicher auch testbar. Ich habe hier auch ältere Versionen ab 6.1 auf dem Rechner zum testen. Wenn es da schneller läuft als mit der aktuellen Version, dann ist das ein Indiz dafür, dass etwas nicht stimmt.

Zur Bildgröße natürlich: Für etwas, das ich auf dem Rechner zu Gesicht bekomme, reicht 150dpi aus. Alle anderen Infos sind unnötiger Ballast. Wenn ich das ausdrucken will, dann begrenze ich das Ganze auf 300 dpi. Das bedeutet: Ein Foto in einem Text in A4 Hochformat mit Rand braucht in der Breite höchstens 2100 Punkte. Meine alte Digitalkamera macht da mehr als das Doppelte draus und belegt damit über 100 MB für das entpackte Bild.

Von einem Normaluser muss ich dennoch erwarten, dass er ein paar dieser Fotos in ein Dokument einbaut und das dann entsprechend ausdrucken will. Und das sollte die Software hergeben.

#14

@Craig22,

Wie teile in Bugzilla mit, dass ich ebenfalls ein großes Interesse an der Behebung eines Bugs habe?

Da kannst selber nicht viel machen.

Am Besten ist es immer einen Bug auf der Mailingsliste bekannt zu geben mit der Bug-Nr bzw. dem Link, mit der Bitte, dass jemand diesen Bug bestätigt und auf “New” setzt.

Der Bug selber sollte immer so ausführlich wie möglich beschrieben werden. Evtl sind Anhänge von Dateien oder Sreenshots erforderlich. (Tritt der Bug in unterschiedlichen Betriebssystem und LibreOffice Versionen auf?)

Danach hängt es von den Entwicklern ab, wann die Bugbearbeitung erfolgt.

#15

Hallo ebot,

Am Besten ist es immer einen Bug auf der Mailingsliste bekannt zu geben mit der Bug-Nr bzw. dem Link, mit der Bitte, dass jemand diesen Bug bestätigt und auf “New” setzt.<<

Derzeit haben alle von mir geposteten Bugs den Status NEW. Teils habe ich die Bug-Nr. auf der Maillngliste bekannt gegeben. Die Beschreibungen meiner Bugs sind sehr ausführlich (nicht übermäßig), inkl. Dateianhänge, Screenshots, Makros. Auch mit welchen Libreoffice-Versionen ich getestet habe.

Nun meine hier gestellte Anfrage ging auch eher in diese Richtung:

Du schreibst einen BUG und ich schreibe in diesen Bug-Report: “Bei mir ist das auch der Fall”

Ist dieses ausreichend, damit ein Report eine höhere Priorität erhält?

Wer zählt?

Die gemeldeten BUGs sind doch eher die absolute Spitze des Eisbergs. Viele Nutzer ärgern sich, aber keiner bestätigt die gemeldeten BUGs. Ausserdem sehe ich BUGs mit Status NEW aus 2014/ 2015…

Mein derzeit ältester Report: Feb.2019

#16

@Craig1,

Mein derzeit ältester Report: Feb.2019

Ist der aktualisiert, z.B. “Fehler tritt in version x.x.x immer noch auf”?

Ansonsten musst du bei den Entwicklern nachfragen, bzw. dort mitarbeiten oder Geld spenden.

TDF/LibreOffice ist eine freie Community. Freie (nicht bezahlte) Mitarbeiter können programmieren (bzw. Fehler beheben) was sie wollen. Andere werden für bestimmte Aufgaben/Projekte bezahlt.

Und wesentlicher Punkt dürfte sein, es sind nicht genug Entwickler da.

Und trotzdem werden bei jedem Release dutzende Fehler und Anforderungen behoben.
Von hier aus mal ein großes Lob an die Entwickler.

Beispiel V7.0: https://wiki.documentfoundation.org/ReleaseNotes/7.0/de

Ist halt bei M$ doch einfacher, wenn der Dollar rollt.

#17

wurde eine Zahl genannt >=7 = hohe Priorität.

Kannte ich bisher nicht. Würde aber heißen, dass der Ersteller des Bugs versuchen müßte andere User zu bewerben/überzeugen, entsprechende Einträge auf Bugzilla zu machen.

Aber du hast recht wir sollten es hier beenden bzw. kannst du zu diesem Thema hier eine separate Frage eröffnen.

Meine kleinen Hinweise waren nur ein Statement kein Vorwurf. Bye, schöne Zeit bleib gesund.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.