LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (http://www.linuxquestions.org/questions/linux-software-2/)
-   -   Has anyone else found LibreOffice to be very, very slow? (http://www.linuxquestions.org/questions/linux-software-2/has-anyone-else-found-libreoffice-to-be-very-very-slow-4175454089/)

rnturn 03-14-2013 02:40 PM

Has anyone else found LibreOffice to be very, very slow?
 
I'm using LO 3.5 and find that, even for very simple documents, that most operations are horribly slow. Just clicking on the "Edit" menu needs several seconds to go by before a menu is even displayed. For example, I want to the change the font of all text so I:

1.) Move the mouse over the "Edit" menu item. (Wait several seconds for the mouse to change from an "insert bar" to a mouse pointer.)

2.) Click on Edit. (Wait several seconds for the menu to appear.)

3.) Click on "Select all". (Hold the mouse button down until the menu selection is highlighted. This takes 2-3 seconds.)

4.) And then... nothing happens. No text, at all, is highlighted.

5.) Give up since no text was selected.

Cut-n-paste operations are interminably slow or just don't work. Trying to select several paragraphs doesn't even work. It's as though the application stops seeing the mouse and never knows where the end of the selected text was supposed to be. It almost feels like I'm working over a very slow link to a remote system.

Uptime showed:
Code:

13:54pm  up 6 days  1:05,  13 users,  load average: 1.78, 1.41, 1.24
Banshee is running but is not using a lot of CPU. There were a whole slew of MySQL processes running that I killed and which brought the load down to 0.5 and below.
Code:

13:59pm  up 6 days  1:10,  13 users,  load average: 0.50, 0.51, 0.66
I found it odd that there would be anyMySQL processes as it's disabled from being started in YaST->System->System Services. Killing the MySQL processes didn't help speed up LO.

There is 2.5GB of RAM and about 10GB of swap spread out across three disks. (hey, what else do you use the space on those gigantic disks?) Current swap use is tiny.

I thought LO was supposed to be ahead of OO but this seems like a major step backwards.

Any ideas what the heck is going on? No other applications I use on a daily basis are acting this way.

Frankly, until I figure out why LO is acting this way, I'm going to have to move back to XEmacs + LaTeX (or [cringe] use my wife's Win7 laptop) to get any writing done. Which makes it more than difficult since the documents are intended for people using Windows (unfortunately).

Any ideas as to what I should try next are greatly appreciated.

--
Rick

273 03-14-2013 02:59 PM

I recall that on my old Athlon Dual-core with 6GB of RAM Libre Office Writer seemed very slow when editing only moderately sized forms I'd received in MS Office format and was verging on the unusable.
I've since built a better PC though and I can't replicate the problem at all. I just opened one of the forms I and problems with and it's only registering about 2.5% CPU load in top.

rnturn 03-14-2013 04:02 PM

Quote:

Originally Posted by 273 (Post 4911687)
I recall that on my old Athlon Dual-core with 6GB of RAM Libre Office Writer seemed very slow when editing only moderately sized forms I'd received in MS Office format and was verging on the unusable.
I've since built a better PC though and I can't replicate the problem at all. I just opened one of the forms I and problems with and it's only registering about 2.5% CPU load in top.

Thanks for the data point. My main desktop system is getting long in the tooth (P4/3.0GHz) but everything else is running acceptably fast. I used to have to go out of my way to make the system run this poorly. But this time it's only LO that's running like molasses in January. All I did was start with an empty document and insert a tab-delimited list of items (from a file) that I then converted to a table. Now that I've done that, LO's performance has turned the document virtually read-only. :^/

I have the same selection of software (OpenSUSE 12.2 + KDE + LO 3.5 + just about everything else) on a Dell Inspiron with (a little) less memory and do not see this degree of slowness with LO. I can do my editing on the laptop, I suppose, though I really cannot stand doing heavy typing on laptop keyboards. (Too darned small, too mushy, and I spend too much time correcting typos. Too many years of Model M muscle memory, I guess.)

There was a note on the LO web site about 4.0 running slow due to a specific version/flavor of Java runtime but the version they recommend using is already on my system. So I'm still a bit baffled by LO's lack of performance.

Again, thanks...

Anyone else got an idea I can pursue?

TIA...

--
Rick

frankbell 03-14-2013 08:52 PM

I have LO on several machines ranging from a Centrino--1000 Ghz with 1 GB RAM to a P4 with 4 GB RAM to an Intel Core i5 with 4 GB RAM.

I've not observed any such behavior. On the older machines, it loads a little slower, but, once it's loaded, the performance is most acceptable.

Whatever the problem may be, I don't think it's LO code.

rnturn 03-15-2013 04:55 PM

Quote:

Originally Posted by frankbell (Post 4911872)
Whatever the problem may be, I don't think it's LO code.

I checked the LO installation on my Dell laptop and, though the menus display more quickly (no multi-second delays), "Edit->Select All" still didn't select all text.

Could this be a change in behavior from OO? (There is now a "selection mode" setting that I don't quite know the purpose of.)

Manually selecting text is still flaky. On both systems trying to select a paragraph (or several paragraphs) rarely works.

I'll try updating to the latest and greatest LO. Perhaps that'll help. Puzzling that the OpenSUSE folks would ship with such a version. (The LO web site doesn't even want to show you the page for the 3.5.x release notes. Could it have been so bad they'd rather forget about it.)

Still looking for answers...

--
Rick

frankbell 03-15-2013 08:34 PM

I was unable to duplicate this:

Quote:

"Edit->Select All" still didn't select all text.
Edit-->Select All worked fine for me in LO 3.5.x on Debian and 3.4.x on Slackware, though I normally use CTRL-A when I'm working with documents). I use LO a lot and haven't encountered any problems, other than of my own making.

Block select appears to mean that you can select a block (lines and what in a text editor are called columns) of text, rather than a continuous lump of it.

rnturn 03-16-2013 12:37 AM

Quote:

Originally Posted by frankbell (Post 4912639)
I was unable to duplicate this:

I was able to get something of a speed-up on my desktop system. Killing off Nepomuk helped a lot. I'm not sure how that even got turned on. Anyway, I made sure that the "Enable Nepomuk" box in "Desktop Configuration->Desktop Search" is unchecked and, hopefully, that'll keep that CPU killer from running from hereon. I remember having problems keeping Beagle from eating all of my CPU cycles on previous Linux systems. (Who uses that stuff, anyway?) It's still a bit of a mystery why only LO seemed to be affected.

I've done a little more testing and, after killing off all the unnecessary search processes, the "Select All" works for most documents. I haven't tried Ctrl-A on everything but I have one document (the one where I originally noticed the LO problems) that refuses to allow "Select All" to work no matter how I invoke it. It may select a cell of a table and nothing else.

Quote:

I use LO a lot and haven't encountered any problems, other than of my own making.
I hadn't had any serious problems before either. I created another document similar to the one where I noticed the original "Select All" problem. Both documents contained only a table of text. For example, a tab-delimited set of objects:
Code:

apple        orange
pear        banana
pineapple        tangerine
grapefruit        kiwi

converted to a table. More complex documents didn't seem to have the text selection problem.

You can still select all but you need to do it before the text-to-table conversion or the resulting table needs to have an empty paragraph above it (this seems to make it "complex" enough) and I can select everything with the mouse. But... I did notice that Ctrl-A would work but it depended on where I had the mouse positioned over the text -- clicking at that position was not required. Just moving the mouse over the center of the page, in the middle near the bottom of the page, or in the right margin, and pressing Ctrl-A worked. Sometimes pressing Ctrl-A only selected part of the text; pressing Ctrl-A a second time would then select all of it. I'm guessing that trying to select all text using the Edit menu doesn't always work because the mouse is not positioned over one of those "magic" areas of the page. Lesson: don't use the menu.

Another odd text selection action I ran across is seen (in many if not all documents) when you double click on the first word of a paragraph and drag to the end of the paragraph without releasing the mouse button. Normally this would just be another way to select the paragraph. (I can't seem to get clicking in the left margin to work consistently.) But what ends up happening is while you're dragging toward the end of the paragraph, text is being highlighted, but when you get to the last line of the paragraph (or maybe just before it), the highlighting disappears even though you haven't released the mouse button. I found that a suitable workaround is to click just to the right of the end of the paragraph and dragging up toward the beginning of the paragraph; everything is selected as you'd expect.

Quote:

Block select appears to mean that you can select a block (lines and what in a text editor are called columns) of text, rather than a continuous lump of it.
Ah... sounds similar to a block select in Emacs which I use so rarely that I usually just select the continuous lump and delete the stuff I don't need. Seems easier than remembering the keystroke sequence that turns on block select.

Anyway... thanks for looking into this. I have a couple of workarounds so we can call this one solved.

--
Rick

frankbell 03-16-2013 09:05 PM

Neopomuk and akonadi are two reasons I stopped using KDE as a desktop and stopped using any KDE applications that use them in the background.

rnturn 03-17-2013 01:02 AM

Quote:

Originally Posted by frankbell (Post 4913122)
Neopomuk and akonadi are two reasons I stopped using KDE...

If I saw a real benefit to a search tool like that, I might not mind it running. (I'm so used to using 'find' for searches it'd take something really slick to get me to switch.) But... I'd like to see any "Enable 'toolname'" checkbox accompanied by another setting, "Run at maximum 'nice'?", to force it to step aside when other, much more important, tasks need to run. I guess that when I replace my motherboards with something supporting 8-core CPUs, maybe I won't mind tools like this running in the background. Nah... I'll still mind.

Later...

--
Rick


All times are GMT -5. The time now is 05:39 AM.