Eingabe in Calc-Dokument sehr langsam

Hallo Leute,

wir benutzen Calc zum Erfassen von Adressen. Ja, das ist nicht die beste Lösung. Eine Datenbank wäre besser geeignet, aber das ist historisch so gewachsen.
Die Tabelle hat mittlerweile eine Zeilenzahl von 17.669 Zeilen , eine Spaltenanzahl von 19 Spalten und eine Größe von 937KiB . In jüngster Zeit ist die Reaktionszeit, bis man nach Eingaben wieder eine Reaktion sehen kann, extrem angestiegen (bis zu 25 Sekunden). Während dieser Zeit steigt auch die CPU-Last auf 100% (für einen Kern).
Wir haben das auf verschiedenen Maschinen ausprobiert und auch mal mit OO. Aber auf fast allen reagiert die Eingabe extrem träge. Auch das Ausschalten der Funktion "Zellinhalte Automatisch berechnen" bringt keine Besserung.

Wir haben mal versucht ein paar Zeiten zu erfassen. Der Test sah folgendermaßen aus :
1.Beliebige Zelle ausgewählt
2.Mit ersten Tastenanschlag die Stoppuhr gestartet und das Wort "Test" mit Enter abgeschlossen.
3.Zeit aufgenommen, wenn Kursor auf die nächste Zelle springt.
4.Abwärtstaste gedrückt gehalten und Zeit aufgenommen, bis sich eine neue Zelle auswählen lässt.

Eine der verwendeten Rechnerkonfiguration ist:
     Intel(R) Core(TM) i7 CPU 920 @8 x 2.67GHz
     8 GB Ram
     OpenSuse 12.1
     LibreOffice 3.5.3.2 Build-ID: 350m1(Build:2)
Bei dieser Konfiguration benötige LO 10 s bis zum Zeilenwechsel und weitere 10 s bis es wieder bereit war für eine neue Eingabe.

Auf einem Thinkpad T61p ging das Ganze unter Linux genauso schnell oder langsam, wie man das sehen will.
Unter WinXP SP3 ging es nur geringfügig schneller.

Eine weitere Auffälligkeit ist, wenn man diese Tabelle offen hat und gleichzeitig auch ein Writer-Dokument, dann dauert der Wechsel zwischen Calc und Writer auch extrem lange.

Möglicherweise kann uns ja hier in der Liste jemand weiterhelfen. Gerne stellen wir auch den Entwicklern, die sich dem Problem annehmen wollen, die besagte Datei zur Verfügung.

Mit Freundlichen Grüßen,

Ronny Kunze
www.digital-ag.de.vu

Hallo Ronny,

wir benutzen Calc zum Erfassen von Adressen. Ja, das ist nicht die beste
Lösung. Eine Datenbank wäre besser geeignet, aber das ist historisch so
gewachsen.
Die Tabelle hat mittlerweile eine Zeilenzahl von 17.669 Zeilen , eine
Spaltenanzahl von 19 Spalten und eine Größe von 937KiB . In jüngster
Zeit ist die Reaktionszeit, bis man nach Eingaben wieder eine Reaktion
sehen kann, extrem angestiegen (bis zu 25 Sekunden). Während dieser Zeit
steigt auch die CPU-Last auf 100% (für einen Kern).
Wir haben das auf verschiedenen Maschinen ausprobiert und auch mal mit
OO. Aber auf fast allen reagiert die Eingabe extrem träge. Auch das
Ausschalten der Funktion "Zellinhalte Automatisch berechnen" bringt
keine Besserung.

Mir scheint nicht, dass so etwas mit der Zeilenzahl zu tun hat. Ich habe
mir gerade einmal ein Testdokument erstellt: Datenbanktabelle mit 6000
Datensätzen, 4* untereinander, zweimal nebeneinander kopiert, so dass 22
Spalten entstehen. Umfang: 1,9 MB

Beim Import braucht Calc. Beim Kopieren innerhalb von Calc geht das
sofort. Die Prozessorlast steigt deutlich beim Abspeichern.

Die Eingabe ist sofort verfügbar und läuft ohne Verzögerung.

Mein System: OpenSuSE 11.4 mit LO 3.3.4 und 3.5.3.2, 32 Bit mit AMD 64
X2 5000+, 2 GB Arbeitsspeicher und Grafik onboard.

Gegenüber Deiner Konfiguration ist das also wie ein Fahrrad, dass das
Motorrad am Hang überholt.

Habt ihr irgendwelche Makros laufen, die beständig dazwischenfunken? Bei
so einem Datenbestand wäre ich ja schon längst zu einer Datenbank
übergewechselt - gerade wegen der Sicherung jedes Datensatzes
unmittelbar nach der Eingabe. Vielleicht hat ja jemand gedacht: Prima,
mache ich mir mit Makros unter Calc auch ...

Gibt es irgendwelche Rechenfunktionen nebenher oder ist das wirklich nur
eine Tabelle? Dann wäre die einfachste Möglichkeit, einmal den gesamten
Bestand durch Kopieren und "Inhalte einfügen" in eine neue Tabelle zu
übernehmen und dort noch einmal zu testen.

Gruß

Robert

Hallo Ronny,

Die Tabelle hat mittlerweile eine Zeilenzahl von 17.669 Zeilen , eine
Spaltenanzahl von 19 Spalten und eine Größe von 937KiB . In jüngster
Zeit ist die Reaktionszeit, bis man nach Eingaben wieder eine Reaktion
sehen kann, extrem angestiegen (bis zu 25 Sekunden).

Kannst Du nachvollziehen, ob da ein Java-Update gelaufen ist? Ich habe
mit Calc nicht so viel zu tun, aber zumindest gibt es unter SuSE (das Du
ja nutzt) eine Unverträglichkeit von Base mit allen SUN-Java_Versionen
nach der 6_u22. Auch bei OpenJDK funktioniert erst die neueste Version
so, dass durch große Datensätze gescrollt werden kann.

Bei Windows waren dann noch Probleme mit dem neuesten Java-Update auf
die Version 7.

Gruß

Robert

Hallo Robert,

ich habe jetzt mal ein Update auf openjdk-1.7.0_147 durchgeführt. Das hat leider keine Verbesserung gebracht.
Makros gibt es auch keine. Ich hatte auch schon mal versucht, die Daten in eine neue Tabelle zu kopieren. Das brachte auch nichts.
Was wir sehr stark nutzen ist das Einfärben Datensätzen . Ich habe jetzt mal die ganze Tabelle in ein Neue kopiert.Ohne dabei die Formatierung mit zu übernehmen. Und siehe da ,sie lässt sich in ordentlicher Geschwindigkeit bearbeiten.

Das Fazit daraus ist das wir unbedingt auf eine Richtige Datenbank migrieren sollten.
Es Hilft doch ungemein wenn man sich mal mit Jemanden über Probleme unterhält.

Vielen Dank für die Hilfe.

Mit Besten Gruß,

Ronny Kunze
www.digital-ag.de.vu

Und in wie vielen dieser Spalten stehen Formeln? Bei /jeder/ Änderung
muss Calc schließlich überprüfen, ob irgend eine der Formeln betroffen
ist, und ggf. neu berechnet werden muss; und je nachdem, wie komplex
Deine Formeln sind, kann das bei immerhin über 335.000 Zellen durchaus
dauern.

Hilft evtl. das Deaktivieren von 'Extras => Zellinhalte => Automatisch
berechnen'?

Wolfgang

Hallo Ronny,

Das Fazit daraus ist das wir unbedingt auf eine Richtige Datenbank
migrieren sollten.

Das dürfte ja eigentlich mit einer Calc-Tabelle kein Problem sein.
Zuerst eine Datenbank mit LO-Base erstellen, dabei die Datenbank auch
anmelden lassen. In der Calc-Tabelle den Datenquellen-Browser öffnen.
Alle Daten markieren und in den Tabellencontainer der Datenbank ziehen.

Beim Import auf die Beschaffenheit der Felder achten. Bei einer
Adresstabelle dürften aber eigentlich nur Varchar-Felder vorhanden sein,
es sei denn, die Postleitzahlen beziehen sich nur auf Deutschland und
sind deswegen eine fünfstellige Ziffernreihenfolge.

Vermutlich habt Ihr keinen Zähler mitlaufen, so dass noch ein
Primärschlüsselfeld gegründet werden muss.

Das Schlüsselfeld wird später zu einem AutoWert-Feld gemacht. Dazu muss
aber die Datenbank erst einmal geöffnet werden.

Und schon kannst Du testen, ob die Eingabe schneller läuft. Denn bereits
die Tabelle bietet ja die einfache Eingabemöglichkeit und um Relationen
habt Ihr Euch bisher ja auch nicht gekümmert, weshalb eine Tabelle
ausreicht.

Diese Variante ist dann auch transportabel von einem auf den anderen
Rechner. Für eine Datenbank im Muliuser-Umfeld reicht das natürlich
nicht. Da kannst Du dann gleich in SuSE MySQL oder auch die externe
aktuelle HSQLDB nutzen.

Gruß

Robert

Hallo Robert,

Das dürfte ja eigentlich mit einer Calc-Tabelle kein Problem sein.

Da hast Du doch glatt eine Steilvorlage für einen (neuen) Abschnitt in dem Handbuch Base vorgegeben - und zwar im Kapitel 07 "Datenbank-Anbindung" bzw. im Unterkapitel "Daten aus Calc in eine Datenbank exportieren".
Dort ist die Vorgehensweise exemplarisch beschrieben.
Der Text Deiner jetzigen eMail ist eine Art Zusammenfassung und passt IMHO gut als eine Art Einführung/Zusammenfassung direkt unter die Kapitelüberschrift "Daten aus Calc in eine Datenbank exportieren".
Wenn Du willst, kann ich das schnell machen.

Gruß

Jochen

Hallo Jochen,

Da hast Du doch glatt eine Steilvorlage für einen (neuen) Abschnitt in
dem Handbuch Base vorgegeben - und zwar im Kapitel 07
"Datenbank-Anbindung" bzw. im Unterkapitel "Daten aus Calc in eine
Datenbank exportieren".
Dort ist die Vorgehensweise exemplarisch beschrieben.
Der Text Deiner jetzigen eMail ist eine Art Zusammenfassung und passt
IMHO gut als eine Art Einführung/Zusammenfassung direkt unter die
Kapitelüberschrift "Daten aus Calc in eine Datenbank exportieren".
Wenn Du willst, kann ich das schnell machen.

Ich gehe davon aus, dass der Export dort schon beschrieben steht.
Zusammen mit dem Handbuch dürfte das schnell nachvollziehbar sein.

Lass uns an der jetzigen Ausführung nichts mehr ändern. Die
Globaldokumente gehen gerade auf den Server.

Gruß

Robert

Hallo Robert,

Lass uns an der jetzigen Ausführung nichts mehr ändern.

o.k.
Ich notiere mir Deine Anmerkungen "privat".
Ich bereite jetzt die Veröffentlichung auf der TDF-Webseite vor. Übernimmst Du die Veröffentlichung im Wiki?

Gruß

Jochen

Hallo,

Was wir sehr stark nutzen ist das Einfärben Datensätzen.

sag das doch gleich. :wink: Das erkenne ich nämlich wieder. Bedingte
Formatierung und mehr noch das Aufzeichnen von Änderungen machen die
Arbeit mit LO Calc zu einer echten Nervenprobe. Das wird auch bei gar
nicht mal so großen Tabellen (unsere hier sind deutlich größer) so lahm,
dass man meint, LO sei abgestürzt. Das kam mit irgendeinem Update vor
gefühlt etwa einem halben Jahr recht plötzlich. Welches Update das war,
habe ich leider nicht mehr in Erinnerung.

Ich will nicht "Jehova!" rufen, aber Excel ist da um ganze
Größenordnungen schneller.

Moin,

Was wir sehr stark nutzen ist das Einfärben Datensätzen.

sag das doch gleich. :wink: Das erkenne ich nämlich wieder. Bedingte
Formatierung und mehr noch das Aufzeichnen von Änderungen machen die
Arbeit mit LO Calc zu einer echten Nervenprobe. Das wird auch bei gar
nicht mal so großen Tabellen (unsere hier sind deutlich größer) so lahm,
dass man meint, LO sei abgestürzt. Das kam mit irgendeinem Update vor
gefühlt etwa einem halben Jahr recht plötzlich. Welches Update das war,
habe ich leider nicht mehr in Erinnerung.

Bitte in solchen Fällen unbedingt einen Bugreport schreiben, falls es noch keinen entsprechenden gibt und auf Nachvollziehbarkeit achten: geeignetes Testdokument dabei?

Ich will nicht "Jehova!" rufen, aber Excel ist da um ganze
Größenordnungen schneller.

Natürlich kann so ein Vergleich zwar zur Orientierung herangezogen werden, hilfreich zum Lösen des Problems ist er jedoch so gut wie kaum.

Gruß Nino

Hallo Ronny,

Gerne stellen wir auch den Entwicklern, die sich dem Problem annehmen wollen,
die besagte Datei zur Verfügung.

es gibt mehrere Dutzend Bugreports – Spreadsheet slow / verschiedene Fälle.
Manche sind aus 3.3.x, in einigen späteren ist die Reden
von Regression zu 3.4.x
<https://bugs.freedesktop.org/show_bug.cgi>

Nur flüchtig überflogen, vielleicht findest du in einem deinen Fall wieder,

Ulrich

Ulrich <ulrichkarim <at> gmail.com> writes:

Hallo Ronny,
  
> Gerne stellen wir auch den Entwicklern, die sich dem Problem
> annehmen wollen, die besagte Datei zur Verfügung.

es gibt mehrere Dutzend Bugreports – Spreadsheet slow / verschiedene Fälle.
Manche sind aus 3.3.x, in einigen späteren ist die Reden
von Regression zu 3.4.x
<https://bugs.freedesktop.org/show_bug.cgi>

Noch ein Versuch mit dem richtigen Link
<https://bugs.freedesktop.org/buglist.cgi?quicksearch=spreadsheet+slow>

Nur flüchtig überflogen, vielleicht findest du in einem deinen Fall wieder,

Ulrich

Hallo Boris

Ich will nicht "Jehova!" rufen, aber Excel ist da um ganze Größenordnungen schneller.

Vielleicht schneller, aber auch wesentlich langsamer als ohne bedingte Formatierung. Außerdem wächst da die Dateigröße sehr schnell. Ich hatte das mal in der Firma probiert: Mehrere Zeilen für einen Kunden und beim nächsten Kunden die Farbe wechseln, damit es übersichtlicher wird. Aus den genannten Gründen habe ich es bald wieder aufgegeben.

Ahoi

Thomas

Hallo,

Natürlich kann so ein Vergleich zwar zur Orientierung herangezogen
werden, hilfreich zum Lösen des Problems ist er jedoch so gut wie kaum.

vielleicht gibt es ja doch einen Hinweis. Dazu habe ich jetzt mal mein
ärgstes Problemkind herangezogen (inzwischen ca. 7MB groß). Unter
Windows XP (32Bit, 2,4GHz, 2GB RAM) geht es sehr zäh: der Wechsel von
einer Zelle zur benachbarten dauert geschätzte 0,3 Sekunden, muss dazu
gescrollt werden, erhöht es sich auf ebenfalls geschätzte 1-2 Sekunden,
was dann schon unangenehm wird. Am besten lässt sich das Speichern
messen: gut dreieinhalb Minuten auf die lokale Platte.

Unter SuSE 12.1 (64Bit, 2,7GHz, 4GB RAM) dauert der Wechsel zur
Nachbarzelle ca. 0,1 Sekunden, also gerade noch sichtbar, wenn man drauf
achtet, mit Scrollen ca. 0,5 Sekunden. Speichern auf einen nfs-Export
über WLAN dauert ca. eine halbe Minute.

Für den Blick über den Tellerrand habe ich das Ding noch nach .xls
exportiert und unter Windows XP mit Excel 2003 geöffnet: Zellwechsel
erfolgt ohne wahrnehmbare Verzögerung, auch mit Scrollen, Speichern ist
in 3 Sekunden erledigt. Allerdings scheinen einige Formate und
Funktionen verlorengegangen zu sein, die Datei ist mit knapp 2MB auch
deutlich kleiner.
Die größten Dateien, die ich je mit Excel bearbeitet hatte, waren ca.
1GB groß, das Speichern dauerte damals gut 10 Minuten. Mit LibreOffice
setze ich mich an einen Versuch erst dann ran, wenn ich ein langes
Wochenende Zeit habe... :wink: Vielleicht gibt es aber schon ein paar
Hinweise, wo man genauer hinsehen müsste.

Hallo,
gerade habe ich die 3.5.4 installiert und bemerkt, dass sich da etwas
getan hat.

vielleicht gibt es ja doch einen Hinweis. Dazu habe ich jetzt mal mein
ärgstes Problemkind herangezogen (inzwischen ca. 7MB groß). Unter
Windows XP (32Bit, 2,4GHz, 2GB RAM) geht es sehr zäh: der Wechsel von
einer Zelle zur benachbarten dauert geschätzte 0,3 Sekunden, muss dazu
gescrollt werden, erhöht es sich auf ebenfalls geschätzte 1-2 Sekunden,

Das geht jetzt schneller, solange nicht gescrollt wird. Mit Scrollen
dauert es immer noch "einundzwanzig - zweiund...".

was dann schon unangenehm wird. Am besten lässt sich das Speichern
messen: gut dreieinhalb Minuten auf die lokale Platte.

Das ist jetzt deutlich schneller geworden. Eine gute halbe Minute (36
Sekunden) dauert es aber immer noch. Nach wie vor verwirrend dabei: nach
bereits 10 Sekunden zeigt der Fortschrittsbalken an, LO sei fertig mit
dem Speichern, doch es reagiert erst wieder nach weiteren 26 Sekunden.
Wer da ungeduldig auf der Tastatur herumklopft, verdirbt sich
möglicherweise seine Daten. Also immer schön vorsichtig!

Hallo,
mir ist noch etwas aufgefallen: sobald Lotus Notes (8.5.1) und LO (3.*)
zeitgleich laufen, fängt eine enorme Festplattenaktivität an, die
mehrere Minuten ununterbrochen anhält und gelegentlich wieder loslegt.
Bei der Kombination Notes & Symphony tritt dasselbe auch auf. Was
ansonsten läuft, scheint dies nicht zu beeinflussen, und mit anderen
Anwendungen (Excel, Firefox, IE...) in beliebiger Kombination (auch mit
Notes) tritt dies auch mit sehr vielen offenen Dokumenten/Fenstern nicht
auf. Auch wenn entweder Notes oder LO nicht läuft, gibt es dieses nicht
in diesem Ausmaß. Also nur die Kombination Lotus Notes mit LO und/oder
Symphony, das Ganze unter Windows XP.

Hat dazu jemand eine Idee?

Hallo,

überprüfe doch mal ob sie in eigener Umgebung oder gemeinsamer laufen.Früher gab es ein ähnliches Problem (allerdings alt und DOS Umgebung unter Windows) weil die Programme bei gemeinsamer Umgebung manches mal auf die selbe Datei (.DLL) zugegriffen haben und das nicht im Speicher passieren konnte.

Behoben konnte es werden, wenn die Datei nicht mit Doppelklick sondern Rechter Mausklick Eigene Umgebung, WIN95 Umgebung etc. gestartet wurde. Wurde natürlich in späteren Programmversionen behoben.

Gruß
Christian

...mir ist noch etwas aufgefallen: sobald Lotus Notes (8.5.1) und LO (3.*)
zeitgleich laufen, fängt eine enorme Festplattenaktivität an, die
mehrere Minuten ununterbrochen anhält und gelegentlich wieder loslegt.
Bei der Kombination Notes & Symphony tritt dasselbe auch auf. ...

Wird halt immer wieder vergessen weil die Entwickler eben nicht jede Software und Hardware Version Testen können.

Gruß
Christian

Hallo,

überprüfe doch mal ob sie in eigener Umgebung oder gemeinsamer
laufen.

da habe ich nur unter Properties->Shortcut->Advaced gefunden:
[x] Run in separate memory space

ausgegraut (nicht änderbar). Meintest Du das?
Oder vielleicht so etwas wie die diversen Kompatibilitätsmodi?

Wird halt immer wieder vergessen weil die Entwickler eben nicht jede
Software und Hardware Version Testen können.

Bei LO lasse ich das noch gelten, bei Symphony aber nicht: der
Hersteller ist ja derselbe, zudem gibt es Symphony auch als in Notes
integrierte Variante. Die möchte ich aber aus zwei Gründen nicht
ausprobieren: zum einen fasse ich Notes nicht an, wenn es denn erst
einmal fehlerarm läuft, zum anderen ist mir Symphony einigermaßen
unsympathisch, schon rein vom Erscheinungsbild und der Bedienung her,
v.a. im Vergleich mit LibreOffice. Aber ein Vergleich gibt mitunter
Hinweise...

Hallo Boris,

Dieses ausgegraute ist es. Kann Dir nur nicht helfen wie man es wieder aktiv bekommt.
Ausgegraut kann zweierlei heißen.

Erstens: Du kannst es nicht wählen (Klar).
Zweitens: Gibt es in Deinem System gar nicht (Nicht installiert) oder wurde abgeschaltet um es zu verwenden. Das führt gerade bei neueren Programmen dazu, es gar nicht erst zu versuchen.

Diesen "Fehler" kann man mit Kompatibilitäts - Modi oft umgehen.

Hallo,

überprüfe doch mal ob sie in eigener Umgebung oder gemeinsamer
laufen.

da habe ich nur unter Properties->Shortcut->Advaced gefunden:
[x] Run in separate memory space

ausgegraut (nicht änderbar). Meintest Du das?

Gruß
Christian