After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708447 - Several operations are very slow
Several operations are very slow
Status: RESOLVED OBSOLETE
Product: Gnumeric
Classification: Applications
Component: General
1.12.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2013-09-20 11:25 UTC by Andres Kuusk
Modified: 2018-05-22 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Backtrace (11.33 KB, text/plain)
2013-09-20 11:25 UTC, Andres Kuusk
Details
A spreadsheet file (29.52 KB, application/spreadsheet)
2013-09-20 11:30 UTC, Andres Kuusk
Details
`ps ax` output (12.18 KB, text/plain)
2013-09-20 14:23 UTC, Andres Kuusk
Details

Description Andres Kuusk 2013-09-20 11:25:47 UTC
Created attachment 255381 [details]
Backtrace

Hello!

On an openSUSE-12.3 PC I have seven windows of rather small sheets open.
Modifying cell format of a few cells take 18s,
closing a window with Ctrl-W take 32s.

Attached are backtrace and a spreadsheet file. 
Other files were of the same structure, just different data.
The backtrace is for the Gnumeric-1.12.0 compiled from source.
The behaviour of Gnumeric from the opanSUSE repository was similar.

Gnumeric worked great on the same hardware with openSUSE-11.4.

Andres Kuusk
Tartu Observatory, Estonia
Comment 1 Andres Kuusk 2013-09-20 11:30:21 UTC
Created attachment 255383 [details]
A spreadsheet file
Comment 2 Morten Welinder 2013-09-20 13:24:42 UTC
Hmm...  For me this file opens in ~1s and closes in <1s.  Changing format
is <<1s.

The change-format backtrace shows gnumeric finished with all operations and
waiting for new input.  I guess you were too late with ctrl-C there.

The exit backtrace looks like a normal stack trace for such an operation.
The weird thing is that it seems to take that long.

What else is running on this machine?  We have had trouble with crazy
clipboard managers before.
Comment 3 Andres Kuusk 2013-09-20 14:23:35 UTC
Created attachment 255402 [details]
`ps ax` output
Comment 4 Andres Kuusk 2013-09-20 14:28:00 UTC
Hi!
> For me this file opens in ~1s and closes in <1s.  Changing format is <<1s.

It is so working with a single file for short time.
Now I worked an hour or two simultaneously on two even more simple files. 
Only copy-past-delete-format operations, copy selected to text file in a separate xterm running vi using mouse buffer, no arithmetics.
Closing these files took tens of seconds.

> I guess you were too late with ctrl-C there.

No, I wosn't. I had a lot of time for Ctrl-C. After Ctrl-C, 'bt' in ddd, and 'Continue' it took some 20s to close the window.

> What else is running on this machine?

I closed most of windows and planned to log out, but this doesn't matter. 
The output of `ps ax` is in the attached file.

-------------
Sorry, I messed my browser window, maybe this is a duplicate submission.
Comment 5 Morten Welinder 2013-09-20 14:37:27 UTC
Nothing stands out there.

Anything unusual going on in /home/andres/.xsession-error
or /var/log/messages?

Any messages when gnumeric is run from the command line?

[I am grasping at straws here -- you have some kind of interaction problem.]
Comment 6 Morten Welinder 2013-09-20 14:58:07 UTC
You appears to have plenty of memory, but just in case: at some point when
things have become slow, please run "top" to see if the Gnumeric process
(or processes, depending on how you run things) have become very big.

For example, upon loading the file from above I see

29225 welinder  20   0  601m  42m  19m S  11.0  2.1   0:01.55 gnumeric                                                               

Hypothetically, if Gnumeric got really big your machine would start swapping
virtual memory and everything -- including non-Gnumeric stuff -- would
become slow.
Comment 7 Andres Kuusk 2013-09-23 16:26:51 UTC
(In reply to comment #6)
> You appears to have plenty of memory, but just in case: at some point when
> things have become slow, please run "top" to see if the Gnumeric process
> (or processes, depending on how you run things) have become very big.

Other things are not slow. When closing of a gnumeric window takes some 20 seconds top shows gnumeric is using 99% CPU.


> Hypothetically, if Gnumeric got really big your machine would start swapping
> virtual memory and everything -- including non-Gnumeric stuff -- would
> become slow.
Swap is empty, now swapping at all.

Closing windows turns slow after working for some hours with numerous windows.
I have been working for several hours on small sheets. Only simple operations:
import small text files, copy/paste small ranges of cells, paste transpose, insert rows/columns, delete rows/columns, copy to text file using mouse buffer and vi in xterm.

I had the problem of large cells. Today I removed all personal settings of the previous (openSUSE-11.4) installation - all $HOME/.* files and directories.
Now the look of Gumeric is normal. 


I have warnings in the xterm where I start gnumeric.

When starting:
** (gnumeric:9893): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

I don't know when appeared the warning:
** (gnumeric:9893): WARNING **: Unknown value 'auto' for (null)

When closing the last window:
** (gnumeric:9893): CRITICAL **: atk_bridge_adaptor_cleanup: assertion `inited' failed


.xsession-error reports some warnings/errors not related to gnumeric:
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols

WARNING: '/etc/xdg/menus/suse-screensavers.menu' does not exist
WARNING: '/etc/xdg/menus/kde-settings.menu' does not exist
WARNING: '/etc/xdg/menus/applications-kmenuedit.menu' does not exist
WARNING: '/etc/xdg/menus/custom.menu' does not exist

[FvwmPager][FlocaleGetFontSet]: (-misc-fixed-*-r-*-*-7-*-*-*-*-*-iso10646-1) Missing font charsets:
JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0
plan: configuration error in X11 resources: yearBoxWidth (class YearBoxWidth) has value 60, minimum is 80.
Run plan -d to see defaults.
plan: configuration error in X11 resources: yearBoxHeight (class YearBoxHeight) has value 24, minimum is 40.
Run plan -d to see defaults.

Some
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  62 (X_CopyArea)
  Resource id in failed request:  0x3c00008
  Serial number of failed request:  315481
  Current serial number in output stream:  315697
I guess these BadDrawables are related to the screensaver.


In /var/log/messages maybe these two messages are the closing of last  gnumeric windows, but I am not sure, I closed several other windows too.
Sep 23 18:02:21 scorpion systemd[1]: Starting Cleanup of Temporary Directories...
Sep 23 18:02:23 scorpion systemd[1]: Started Cleanup of Temporary Directories.

Other messages are not related to gnumeric.
Comment 8 Matthias Clasen 2015-01-11 20:31:44 UTC
This may have been fixed by commit 430ea2fff639f31b868e025002a32ba473c7bd07
Comment 9 Morten Welinder 2015-01-11 22:58:33 UTC
Matthias: did you mean to edit this bug or some other bug?
Comment 10 Matthias Clasen 2015-01-12 17:45:22 UTC
the commit I pointed to fixes a failure to ignore spurious BadDrawable errors, but I agree the connection to this bug is a bit tenuous
Comment 11 Worik Stanton 2015-05-25 01:47:03 UTC
Joining this bug, as I find sorting and searching very slow.

Looking at top I see gnumeric sits at 100% for (subjectively) many seconds.

I have 16G of memory and a spreadsheet of about 120 rows and 18 columns.


I am happy to dig more and give more data if that would be helpful, but I see there is a bit of activity around this so I will hold off until some one asks.
Comment 12 GNOME Infrastructure Team 2018-05-22 14:04:38 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/237.