Writer hängt ein paar Sekunden nach dem Speichern - 5.2.6.2 Win7 64bit

de-users
#1

Hallo Liste,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Einer der Texte hat 472kB im odt (~367 Seiten, 405 Bilder).
472kB ist ja nicht so viel.

Dummerweise wird das Arbeiten nun erschwert weil beim
Abspeichern erst der Scrollbalken abgearbeitet wird und
danach jedoch ~5s vergehen bevor das System wieder
auf Eingaben brauchbar reagiert.

Bei einem anderen Text mit 768 Seiten gab es bisher nie
Probleme.

Beim Versuch eine Testdatei zu erstellen habe ich festgestellt
daß das Problem scheinbar nicht auftritt wenn die Bilder
nicht auf der Platte erreichbar sind. Dann werden nur
Rahmen stattdessen angezeigt.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005* <https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer hangs several seconds after saving

Leider kann ich mit der sicher gutgemeinten Antwort von Timur
nicht viel anfangen. Siehe seinen Text unten.

Ich habe Win7 64bit, keine anderen Versionen.
Ein Crash tritt wohl nicht auf - was also hilft ein Crash-Report
wenn es keinen Crash gibt - nur diese Verzögerung?

Hat jemand eine Idee wie dem Problem beizukommen ist?
Kennt jemand vielleicht so ein Verhalten?

Natürlich kann ich neuere Versionen grundsätzlich testen.
Nur benötige ich ein produktives System. Es darf nicht passieren
daß ich mein System zerstöre und dann neuinstallieren muss.
Es dauert Tage den Rechner neu aufzubauen mit den Applikationen
die laufen müssen.

Ich helfe gerne - nur nicht um jeden Preis.
Mit der Bitte um Verständnis.

Vielen Dank !
Matthias

Thank you, but this can't be conformed like this, even that I'm seeing some unresponsability myself.
You should either attach minimal test case to reproduce a bug or test this yourself.

I'm suggesting that you:
- gethttp://tdf.io/siguiexe to easily get and run "parallel" LO in Windows (extract without installation)
- run different extracted versions (here it would be fresh 5.3.3.2 and 5.4 beta and master 5.5+) and architectures (32-bit or 64-bit) related to this bug in order to test crash
- note crash report link for crash with LO 5.2 and higher, sth. like crashreport.libreoffice.org/stats/crash_details/.... (not applicable here but a general advice)

and, if possible, since it's not overly complicated, but gives some clues:
- use procdump (part of free and useful Sysinternaly Suite) during LO run in order to get a dump (soffice.bin.dmp)
- run procdump manually after LO start (path-to\SYSINTERNALSSUITE\procdump.exe soffice.bin -h path-to\soffice.bin.dmp) for reproducible bugs like this one, OR via simple batch file likeattachment 129814 <http://bugs.documentfoundation.org/attachment.cgi?id=129814> [details] <http://bugs.documentfoundation.org/attachment.cgi?id=129814&action=edit>, that is used instead of LO icon to start LO, for intermittent bugs (which seems to be the case here)

and even this - or just upload previous crash dump with LO "Master x86 39":
- analyze dump with WinDbg configured perhttps://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg (set "Symbol File Path")
- attach here as an attachment result of "!analyze -v" command in WinDbg (that's "backtrace")
- if "!analyze -v" is empty, which comes after "ntdll!NtTerminateProcess" error, go with "kb" that prints stack trace and "~* kp" to dump the whole stack.

#2

Hallo Matthias,

verstehe ich da was falsch oder haben Deine Angaben einen Fehler? Das sind ja nur etwa 1 kB pro Bild?
Das kommt mir seeehr wenig vor.

Beste Grüße

Markus

#3

Hallo Markus,

dies ist die Größe von Text mit Bild-Links.
Die Bilder selbst sind bei dieser Größe nicht dabei.
Diese liegen ja separat in einem Ordner.

Die Größen sind recht unterschiedlich.
Es sind recht kleine dabei und auch etwas größere.

Meist sind es png-Dateien.
Die größte hat 6.9MB, die zweitgrößte 4MB, dann
kommen wenige um 2MB, ein paar um 1MB und
dann deutlich kleinere. Da kleinste Bild hat 1kB.

Beim Abspeichern werden die Bilder ja nicht
verändert. Daher sollte die Zeit hauptsächlich
für das Speichern des odt verwendet werden.

Was macht LO 5s noch danach wenn das
Speichern beendet ist?

Beste Grüße
Matthias

#4

Hallo Dr. Matthias Weisser,

Was macht LO 5s noch danach wenn das
Speichern beendet ist?

Das könntest Du zuverlässig rausfinden, indem Du einfach procmon, den
Prozess-Monitor aus der bereits erwähnten Sysinternal-Suite, parallel
mitlaufen lässt. In der Ansicht dann alle Zeilen mit soffice einschließen.

#5

Hallo Matthias,

Hallo Liste,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Einer der Texte hat 472kB im odt (~367 Seiten, 405 Bilder).
472kB ist ja nicht so viel.

Dummerweise wird das Arbeiten nun erschwert weil beim
Abspeichern erst der Scrollbalken abgearbeitet wird und
danach jedoch ~5s vergehen bevor das System wieder
auf Eingaben brauchbar reagiert.

Bei einem anderen Text mit 768 Seiten gab es bisher nie
Probleme.

Beim Versuch eine Testdatei zu erstellen habe ich festgestellt
daß das Problem scheinbar nicht auftritt wenn die Bilder
nicht auf der Platte erreichbar sind. Dann werden nur
Rahmen stattdessen angezeigt.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005*
<https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer
hangs several seconds after saving

Leider kann ich mit der sicher gutgemeinten Antwort von Timur
nicht viel anfangen. Siehe seinen Text unten.

die Antwort von Timur ist sicherlich für "Laien" etwas kryptisch.

Wichtig für die Bearbeitung von Bug Reports ist, dass Dein Problem von
anderen nachvollzogen werden kann. Dazu müsstest Du eine entsprechende
Testdatei als Anhang an den Bug Report zur Verfügung stellen.

Wichtig für den Bug Report wäre auch noch, ob Dein Problem bei allen
LO-Versionen auftritt oder erst ab einer bestimmten Version. Um dieses
zu testen, kannst Du frühere Versionen parallel installieren. Hier
steht, wie es geht:

https://wiki.documentfoundation.org/Installing_in_parallel/de

Grüße
Harald K.

#6

Danke Harald !

eine odt-Testdatei habe ich. Nur hilft diese alleine nichts,
denn ohne den Ordner mit den vielen Bildern tritt das
Problem nicht auf.

Zu Deiner Frage ob das Problem bei allen LO-Versionen
auftritt habe ich festgestellt daß die 4.3.7.2 noch ok ist
und die 4.4.7.2 auch.
Der Fehler tritt bei der 5.1.6 auf - wobei es egal ist ob
es die 32bit oder 64bit-Variante ist. Es klemmt bei beiden.

Um dies zu testen habe ich einen neu aufgesetzten Rechner
genommen mit Win7 64bit und nacheinander die einzelnen
Versionen installiert - zuerst die 4.3.7.2, dann 4.4.7.2,
dann 5.1.6 32bit und dann 5.1.6 64bit.

Grüße
Matthias

#7

Hallo Harald und Liste,

ich habe das Verhalten nun mit einem neu aufgesetzten
Laptop unter Win7 64bit mit verschiedenen Versionen
von LO - die nacheinander installiert wurden - überprüft.

_Ergebnis:_
+ 4.3.7.2 ist ok - kein Problem mit 5s Wartezeit nach dem Speichern
+ 4.4.7.2 ist ok.
- 5.1.6 ist nicht ok - egal ob 32 oder 64bit-Variante.
- 5.2.7 ist nicht ok.
- 5.3.3 ist nicht ok. Diese Version lädt zudem zäher.
- 5.4.0 bringt beim Versuch zu installieren die Meldung
"Das Programm kann nicht gestartet werden, da api-ms-win-crt-runtime...dll auf dem Computer fehlt.
Installieren Sie das Programm erneut.."

Neuinstallation führt wieder zum selben Fehler.

_Fazit:_
Die letzte Version die für meine Bücher halbwegs brauchbar
arbeitete ist die 4.4.7.2.
Bei der 4.4.7.2 trat jedoch ein Problem beim Hinzufügen
von Grafiken auf. Ich schrieb dazu einen Issue:
*Bug 100103* <https://bugs.documentfoundation.org/show_bug.cgi?id=100103> - Writer hangs when graphics are added

Dieses Problem verschwand mit LO 5.0.6.

Damit gibt es leider momentan keine neuere Version die ich
problemlos nutzen kann. Innerhalb der 5er Version scheint
das Arbeiten im Vergleich zur 4er nicht besser zu werden
sondern zäher und damit schlechter.

Keine Ahnung ob das so gewollt ist.
Es entwickelt sich aus meiner Sicht als Autor von Büchern
in die falsche Richtung.

Einen Text kann ich zur Verfügung stellen, aber nicht
die ganzen internen Bilder meines Buchs. Diese sollen
nicht öffentlich werden. Wer das privat für sich nachvollziehen
möchte ohne die Bilder öffentlich zu machen möge sich
bitte melden.

Grüße
Matthias

#8

Hallo Matthias,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Einer der Texte hat 472kB im odt (~367 Seiten, 405 Bilder).
472kB ist ja nicht so viel.

Dummerweise wird das Arbeiten nun erschwert weil beim
Abspeichern erst der Scrollbalken abgearbeitet wird und
danach jedoch ~5s vergehen bevor das System wieder
auf Eingaben brauchbar reagiert.

Beim Versuch eine Testdatei zu erstellen habe ich festgestellt
daß das Problem scheinbar nicht auftritt wenn die Bilder
nicht auf der Platte erreichbar sind. Dann werden nur
Rahmen stattdessen angezeigt.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005*
<https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer
hangs several seconds after saving

Wichtig für die Bearbeitung von Bug Reports ist, dass Dein Problem von
anderen nachvollzogen werden kann. Dazu müsstest Du eine entsprechende
Testdatei als Anhang an den Bug Report zur Verfügung stellen.

Wichtig für den Bug Report wäre auch noch, ob Dein Problem bei allen
LO-Versionen auftritt oder erst ab einer bestimmten Version. Um dieses
zu testen, kannst Du frühere Versionen parallel installieren. Hier
steht, wie es geht:

https://wiki.documentfoundation.org/Installing_in_parallel/de

Grüße
Harald K.

Danke Harald !

eine odt-Testdatei habe ich. Nur hilft diese alleine nichts,
denn ohne den Ordner mit den vielen Bildern tritt das
Problem nicht auf.

probier doch mal aus, ob das Problem noch vorhanden ist, wenn Du das
gleiche Bild mehrfach in Dein Dokument einfügst. Wenn ja, dann bitte
auch noch mal mit der Version 4.4.7 prüfen, ob das Problem dort noch
nicht vorhanden ist.

Zu Deiner Frage ob das Problem bei allen LO-Versionen
auftritt habe ich festgestellt daß die 4.3.7.2 noch ok ist
und die 4.4.7.2 auch.
Der Fehler tritt bei der 5.1.6 auf - wobei es egal ist ob
es die 32bit oder 64bit-Variante ist. Es klemmt bei beiden.

Ich habe noch in Bugzilla nach Bugs in den Versionen ab 5.0.x.x gesucht,
bei denen es Performance-Probleme in Zusammenhang mit Bildern gibt. Es
gibt dort einige Meldungen, aber ob es sich dabei um das gleiche Problem
handelt ist schwer zu sagen (Bugs 96143, 93869, 94109, 94184, 104716,
96095, 103873).

Grüße
Harald

#9

Hallo Matthias,

Dr. Matthias Weisser schrieb:

Hallo Harald und Liste,

ich habe das Verhalten nun mit einem neu aufgesetzten
Laptop unter Win7 64bit mit verschiedenen Versionen
von LO - die nacheinander installiert wurden - überprüft.

_Ergebnis:_
+ 4.3.7.2 ist ok - kein Problem mit 5s Wartezeit nach dem Speichern
+ 4.4.7.2 ist ok.
- 5.1.6 ist nicht ok - egal ob 32 oder 64bit-Variante.
- 5.2.7 ist nicht ok.
- 5.3.3 ist nicht ok. Diese Version lädt zudem zäher.
- 5.4.0 bringt beim Versuch zu installieren die Meldung
"Das Programm kann nicht gestartet werden, da
api-ms-win-crt-runtime...dll auf dem Computer fehlt.
Installieren Sie das Programm erneut.."

Packe diese Version mal nur aus:
(1)Gehe über Start > Ausführen > Schaltläche durchsuchen.
(2)Navigiere zu der LO .msi Datei. Du musst im Explorer die Vorauswahl von "Progamme" auf "Alle Dateien" stellen, sonst siehst du die msi-Datei nicht. Öffnen.
(3) Nun hast du im Ausführen-Dialog im Feld Öffnen den Dateinamen stehen. Clicke zweimal in diese Zeile, so dass du einen Cursor hast, aber nichts markiert ist. Bewege den Cursor ganz an den Anfang des Eingabefeldes und ergänze den Text "msiexec -a " (ohne die " !).
(4) Klicke OK und führe die Installation durch. Es wird nicht wirklich installiert, sondern es wird alles in ein Verzeichnis deiner Wahl entpackt.
(5) In diesem Verzeichnis findest du einen Ordner "System". Der enthält alle die dll's für Windows.

Bei mir (Windows 7, 32bit) wurden Sie bei einer normalen Installation allerdings problemlos nach Windows/System32 kopiert. Ich weiß nicht, woran es bei dir gescheitert haben könnte. Du kannst die fehlende dll aber auch einfach von Hand kopieren. Suche im Windowsverzeichnis nach api-ms-win damit du weißt, wohin die fehlende Datei muss.

Du kannst auch mit der entpackten Version arbeiten. Ändere in der Datei bootstrap.ini in der Zeile UserInstallation den Wert auf $ORIGIN/.. und starte LibreOffice dann mit Doppelklick auf soffice.exe.

Mit freundlichen Grüßen
Regina

#10

Hallo Harald,

Hallo Matthias,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Einer der Texte hat 472kB im odt (~367 Seiten, 405 Bilder).
472kB ist ja nicht so viel.

Dummerweise wird das Arbeiten nun erschwert weil beim
Abspeichern erst der Scrollbalken abgearbeitet wird und
danach jedoch ~5s vergehen bevor das System wieder
auf Eingaben brauchbar reagiert.

Beim Versuch eine Testdatei zu erstellen habe ich festgestellt
daß das Problem scheinbar nicht auftritt wenn die Bilder
nicht auf der Platte erreichbar sind. Dann werden nur
Rahmen stattdessen angezeigt.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005*
<https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer
hangs several seconds after saving

Grüße
Harald K.

Danke Harald !

eine odt-Testdatei habe ich. Nur hilft diese alleine nichts,
denn ohne den Ordner mit den vielen Bildern tritt das
Problem nicht auf.

probier doch mal aus, ob das Problem noch vorhanden ist, wenn Du das
gleiche Bild mehrfach in Dein Dokument einfügst.

das ist leider nicht so einfach zu machen, denn es sind ja 405 Bilder die ich da einzeln anfassen müsste.
Momentan weiß ich nicht wie das rasch zu erledigen ist. Bei 20 Bildern wäre es mit copy/paste noch machbar.
Die Rahmengrößen ändern sich dann jedoch auch.
Dazu wäre ein Skript hilfreich. Ich habe jedoch keines.

Wenn ja, dann bitte
auch noch mal mit der Version 4.4.7 prüfen, ob das Problem dort noch
nicht vorhanden ist.

bei der 4.4.7.2 tritt das Problem nicht auf.

Zu Deiner Frage ob das Problem bei allen LO-Versionen
auftritt habe ich festgestellt daß die 4.3.7.2 noch ok ist
und die 4.4.7.2 auch.
Der Fehler tritt bei der 5.1.6 auf - wobei es egal ist ob
es die 32bit oder 64bit-Variante ist. Es klemmt bei beiden.

Ich habe noch in Bugzilla nach Bugs in den Versionen ab 5.0.x.x gesucht,
bei denen es Performance-Probleme in Zusammenhang mit Bildern gibt. Es
gibt dort einige Meldungen, aber ob es sich dabei um das gleiche Problem
handelt ist schwer zu sagen (Bugs 96143, 93869, 94109, 94184, 104716,
96095, 103873).

Danke Harald !

Grüße
Matthias

#11

Hallo Matthias,

vorab: Meine Konfiguration ähnelt Deiner, also Win 7 pro, 64 bit, 12 GB Hauptspeicher; LO: 5.2.5.1 (x64), Bilder sind per Verweis eingebunden.

Gestartet bin ich mit einer Datei unter LO 4.x - dies wurde ab ca. 80 Seiten so instabil, daß ich mich entschloß, auf ein Global-Dokument umzustellen - dabei bin ich den Empfehlungen zum Vorgehen gefolgt.

Auch hier bin ich unter LO 4.x in eine Stabilitätsfalle geraten - und habe mich erstmal um andere Dinge gekümmert.

Einige Versionen später unter LO 5.x (x64) war es dann so richtig rund und stabil - wie ich es als "halber DAU" erwarte.

Einzige Einschränkung: In der Zeit der Instabilität habe ich mir angewöhnt, den Task-Manager laufen zu lassen - erst wenn sich CPU- und Speicheraktivitäten nach dem Öffnen, Drucken, Speichern oder Schließen "beruhigt" haben, geht es für mich weiter.

Mein Global-Dokument umfaßt ca. 15 Kapitel unterschiedlicher Größe, knapp 200 Bildern mit zusammen ca. 600 MB.
Ich habe eben das Global-Dok testweise in eine normale .odt-Datei exportiert - keine Änderung beim Verhalten.

Vielleicht hilft Dir meine Antwort...

Viele Grüße aus Hannover, Klaus

#12

Danke für die Hinweise Klaus !

Ein Globaldokument möchte ich nicht verwenden.
Bisher ist es ohne gegangen - und das sollte
auch weiterhin so möglich sein.

Natürlich kann ich den Taskmanager mal beobachten.
Bei der 4er Version habe ich das gemacht.
Manchmal dauert es eine ganze Weile bis die
Aktivität dann endlich verschwindet.

Man weiß dann nicht so genau was das
Programm da wirklich macht.

Instabilitäten hatte ich bei der 4er Version
wenn 3 recht große Bilder direkt hintereinanderkamen.

Bei der 5er ging das besser.

Nur gibt es nun eben neue Macken die man
erst mal verstehen muss.

Programme mit weniger Macken liebt man natürlich mehr.

Viele Grüße nach Hannover
Matthias

#13

Danke Regina für die Hinweise !

Es hat geklappt die 5.4.0 in einen Ordner C:\lo entpacken zu lassen.

Die api-ms-win-crt-runtime...dll ist in diesem Ordner.
Ich habe sie dann nach windows/system32 kopiert.
Das brachte den Fehler nicht weg weil es ja ein Win64 ist.
Durch Kopieren der dll nach sysWOW64 verschwand der Fehler.

Leider gibt es beim Aufrufen der 5.4. nun den
Fehler "Der Prozedureinsprungpunkt "ucrtbase.terminate"
wurde in der api-ms-win-crt-runtime...dll nicht gefunden."

Gibt es da eine Idee woran das liegen kann?

Die 5.4.0 scheint auf diesem Rechner nicht so leicht
installierbar zu sein. Dabei war er neu aufgesetzt !
Die LO-Versionen davor hatte ich jedoch nicht deinstalliert
vor der Installation der nächsten Variante.

Freundliche Grüße
Matthias

#14

Hallo Matthias,

Hallo Harald,

Hallo Matthias,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf
Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Einer der Texte hat 472kB im odt (~367 Seiten, 405 Bilder).
472kB ist ja nicht so viel.

Dummerweise wird das Arbeiten nun erschwert weil beim
Abspeichern erst der Scrollbalken abgearbeitet wird und
danach jedoch ~5s vergehen bevor das System wieder
auf Eingaben brauchbar reagiert.

Beim Versuch eine Testdatei zu erstellen habe ich festgestellt
daß das Problem scheinbar nicht auftritt wenn die Bilder
nicht auf der Platte erreichbar sind. Dann werden nur
Rahmen stattdessen angezeigt.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005*
<https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer
hangs several seconds after saving

Grüße
Harald K.

Danke Harald !

eine odt-Testdatei habe ich. Nur hilft diese alleine nichts,
denn ohne den Ordner mit den vielen Bildern tritt das
Problem nicht auf.

probier doch mal aus, ob das Problem noch vorhanden ist, wenn Du das
gleiche Bild mehrfach in Dein Dokument einfügst.

das ist leider nicht so einfach zu machen, denn es sind ja 405 Bilder
die ich da einzeln anfassen müsste.
Momentan weiß ich nicht wie das rasch zu erledigen ist. Bei 20 Bildern
wäre es mit copy/paste noch machbar.
Die Rahmengrößen ändern sich dann jedoch auch.
Dazu wäre ein Skript hilfreich. Ich habe jedoch keines.

es hat ja inzwischen einen umfangreichen Mail-Verkehr gegeben. Mein
Eindruck ist aber, dass das ursprüngliche Problem nach wie vor vorhanden
ist. Vielleicht lässt sich das Problem ja schon nachvollziehen, wenn Du
ein großes neues Dokument erstellst, dass Du durch mehrfaches Kopieren
von Text und eines eingefügten Bildes relativ schnell erstellen kannst.

Bei einem Performance-Problem wird man in der Regel immer eine Testdatei
benötigen. Nur wenn Du eine solche Testdatei zu Verfügung stellen
kannst, wird es möglich sein, den Bug weiter zu bearbeiten.

Wenn ja, dann bitte
auch noch mal mit der Version 4.4.7 prüfen, ob das Problem dort noch
nicht vorhanden ist.

bei der 4.4.7.2 tritt das Problem nicht auf.

Hiermit meine ich einen Test mit der neu erstellten Testdatei, um sicher
zu gehen, dass es sich um das ursprüngliche Problem handelt.

Zu Deiner Frage ob das Problem bei allen LO-Versionen
auftritt habe ich festgestellt daß die 4.3.7.2 noch ok ist
und die 4.4.7.2 auch.
Der Fehler tritt bei der 5.1.6 auf - wobei es egal ist ob
es die 32bit oder 64bit-Variante ist. Es klemmt bei beiden.

Du hast in einer anderen Mail berichtet, dass es bei der Version 5.3.3
ein Performance-Problem beim Scrollen auftritt, dass in der Version
5.2.7 noch nicht vorhanden war. Ist es richtig, dass dieses Problem
nichts mit dem ursprünglichen Problem beim Speichern zu tun hat?

Weiterhin hast Du in ein anderen Mail zu diesem Thema gefragt, wann es
sinnvoll ist, einen Bug Report bei Performance-Problemen zu erstellen.
Immer sinnvoll ist dies, wenn eine Funktion in einer neueren Version
signifikant langsamer ist, als in einer älteren Version. Sinnvoll kann
dies auch sein, wenn eine Funktion 'gefühlt' zu lange dauert. Allerdings
lassen sich Latenzzeiten nicht grundsätzlich vermeiden, wenn
umfangreiche Daten zu bewegen oder auszuwerten sind.

Grüße
Harald K.

#15

Hallo Harald,

bezüglich "Writer hängt ein paar Sekunden nach dem Speichern - 5.2.6.2 Win7 64bit" gibt es einen BugReport ( https://bugs.documentfoundation.org/show_bug.cgi?id=98731 ).
Ab Eintrag "2017-05-26 20:10:27 UTC" ist ersichtlich, dass das Problem erkannt, nachvollziehbar und in Bearbeitung ist. Der BugReport bezieht sich zwar auf "Windows 10" und "LO 5.1.1.3", aber unter "LO 5.2.7.2 (x64)" kann ich diesen Effekt auch bestätigen. Unter Eintrag "2016-03-31 22:58:34 UTC" im BugReport ist auch ein Link zu einer Testdatei angegeben, der noch funktioniert. Bei dieser relativ kleinen Testdatei ist der Verzögerungseffekt nur von relativ kurzer Dauer. Ich hatte mir eine größere Testdatei (600 MB, 1401 Tabellen, 2732 Bilder, 102146 Zeichen) zusammengestellt und da ist der Effekt schon wesentlich spürbarer.

Gruß
Hans-Werner

------ Originalnachricht ------

#16

Danke Harald,

Hallo Matthias,

Hallo Harald,

Hallo Matthias,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf
Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Einer der Texte hat 472kB im odt (~367 Seiten, 405 Bilder).
472kB ist ja nicht so viel.

Dummerweise wird das Arbeiten nun erschwert weil beim
Abspeichern erst der Scrollbalken abgearbeitet wird und
danach jedoch ~5s vergehen bevor das System wieder
auf Eingaben brauchbar reagiert.

Beim Versuch eine Testdatei zu erstellen habe ich festgestellt
daß das Problem scheinbar nicht auftritt wenn die Bilder
nicht auf der Platte erreichbar sind. Dann werden nur
Rahmen stattdessen angezeigt.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005*
<https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer
hangs several seconds after saving

Grüße
Harald K.

Danke Harald !

eine odt-Testdatei habe ich. Nur hilft diese alleine nichts,
denn ohne den Ordner mit den vielen Bildern tritt das
Problem nicht auf.

probier doch mal aus, ob das Problem noch vorhanden ist, wenn Du das
gleiche Bild mehrfach in Dein Dokument einfügst.

das ist leider nicht so einfach zu machen, denn es sind ja 405 Bilder
die ich da einzeln anfassen müsste.
Momentan weiß ich nicht wie das rasch zu erledigen ist. Bei 20 Bildern
wäre es mit copy/paste noch machbar.
Die Rahmengrößen ändern sich dann jedoch auch.
Dazu wäre ein Skript hilfreich. Ich habe jedoch keines.

es hat ja inzwischen einen umfangreichen Mail-Verkehr gegeben.

ja. Das ist so.

Mein Eindruck ist aber, dass das ursprüngliche Problem nach wie vor vorhanden
ist.

so ist es.

Vielleicht lässt sich das Problem ja schon nachvollziehen, wenn Du
ein großes neues Dokument erstellst, dass Du durch mehrfaches Kopieren
von Text und eines eingefügten Bildes relativ schnell erstellen kannst.

ich habe eine Testdatei erstellt auf Basis meines Texts
und einem Bild. Das war mühsam weil ich die vielen
Bilder mit einem ersetzt habe.
Das Verhalten ist so ähnlich.
Ein neues Problem ist dabei noch aufgetaucht.
Das Ersetzen von Bildern klappt nicht immer wie gewünscht.
Manchmal wird das neue Bild ungewollt an anderer Stelle eingefügt.

Bei einem Performance-Problem wird man in der Regel immer eine Testdatei
benötigen. Nur wenn Du eine solche Testdatei zu Verfügung stellen
kannst, wird es möglich sein, den Bug weiter zu bearbeiten.

daher nun die Testdatei.

Wenn ja, dann bitte
auch noch mal mit der Version 4.4.7 prüfen, ob das Problem dort noch
nicht vorhanden ist.

bei der 4.4.7.2 tritt das Problem nicht auf.

Hiermit meine ich einen Test mit der neu erstellten Testdatei, um sicher
zu gehen, dass es sich um das ursprüngliche Problem handelt.

ja.

Zu Deiner Frage ob das Problem bei allen LO-Versionen
auftritt habe ich festgestellt daß die 4.3.7.2 noch ok ist
und die 4.4.7.2 auch.
Der Fehler tritt bei der 5.1.6 auf - wobei es egal ist ob
es die 32bit oder 64bit-Variante ist. Es klemmt bei beiden.

Du hast in einer anderen Mail berichtet, dass es bei der Version 5.3.3
ein Performance-Problem beim Scrollen auftritt, dass in der Version
5.2.7 noch nicht vorhanden war. Ist es richtig, dass dieses Problem
nichts mit dem ursprünglichen Problem beim Speichern zu tun hat?

ja. Man kann einen eigenen Issue daraus machen.

Weiterhin hast Du in ein anderen Mail zu diesem Thema gefragt, wann es
sinnvoll ist, einen Bug Report bei Performance-Problemen zu erstellen.
Immer sinnvoll ist dies, wenn eine Funktion in einer neueren Version
signifikant langsamer ist, als in einer älteren Version. Sinnvoll kann
dies auch sein, wenn eine Funktion 'gefühlt' zu lange dauert. Allerdings
lassen sich Latenzzeiten nicht grundsätzlich vermeiden, wenn
umfangreiche Daten zu bewegen oder auszuwerten sind.

Latenzzeiten in der Größenordnung mehrere Sekunden ohne daß man weiß daß LO etwas macht sind lähmend und frustrierend. So ist meine subjektive Meinung.

Grüße
Matthias

#17

Hallo Harald,

Hallo Matthias,

Hallo Harald,

Hallo Matthias,

ich schreibe Bücher mit vielen Bildern - eingebettet als Link auf
Datei.
LO ist im Einsatz unter Win7 64bit in der Version 5.2.6.2.

Weil das Problem mich behindert habe ich einen Issue
erstellt und das Verhalten geschildert.
*Bug 108005*
<https://bugs.documentfoundation.org/show_bug.cgi?id=108005> - Writer
hangs several seconds after saving

es hat ja inzwischen einen umfangreichen Mail-Verkehr gegeben. Mein
Eindruck ist aber, dass das ursprüngliche Problem nach wie vor vorhanden
ist. Vielleicht lässt sich das Problem ja schon nachvollziehen, wenn Du
ein großes neues Dokument erstellst, dass Du durch mehrfaches Kopieren
von Text und eines eingefügten Bildes relativ schnell erstellen kannst.

Bei einem Performance-Problem wird man in der Regel immer eine Testdatei
benötigen. Nur wenn Du eine solche Testdatei zu Verfügung stellen
kannst, wird es möglich sein, den Bug weiter zu bearbeiten.

die Testdatei gibt es nun.

Du hast in einer anderen Mail berichtet, dass es bei der Version 5.3.3
ein Performance-Problem beim Scrollen auftritt, dass in der Version
5.2.7 noch nicht vorhanden war. Ist es richtig, dass dieses Problem
nichts mit dem ursprünglichen Problem beim Speichern zu tun hat?

zu diesem Problem gibt es nun einen Issue nebst Testdatei:
*Bug 108388* <https://bugs.documentfoundation.org/show_bug.cgi?id=108388> - very slow scrolling in comparison to LO5.2.7.2

Weiterhin hast Du in ein anderen Mail zu diesem Thema gefragt, wann es
sinnvoll ist, einen Bug Report bei Performance-Problemen zu erstellen.
Immer sinnvoll ist dies, wenn eine Funktion in einer neueren Version
signifikant langsamer ist, als in einer älteren Version. Sinnvoll kann
dies auch sein, wenn eine Funktion 'gefühlt' zu lange dauert.

Danke Harald !

Es gibt noch ein weiteres Problem das beim Erstellen der Testdatei aufgefallen ist.
Die vielen Bilder im Buch habe ich mit Copy/Paste durch ein anderes Bild ersetzt.
Dabei ist aufgefallen daß dieses Ersetzen - wobei man das Bild das man
ersetzen möchte anklickt - so daß es markiert ist - und dann Paste drückt -
nicht immer korrekt klappt.

Manchmal wird nicht das Bild genau an dieser Stelle ersetzt - sondern das
Bild verschwindet und das neue Bild landet unerwünscht an einer anderen Stelle.
Dabei waren alle Bilder "als Zeichen" "am Zeichen" formatiert.

Dieses Problem sollte man sich näher ansehen.

Grüße
Matthias