High CPU usage, apps locking up on find/replace operations

[paul1149]

Thanks. I've now disabled Java, which I think is necessary for macro recording, but I haven't been doing much of that. I think the effect of recent docs pertains mostly to remote files, so I've left most of them. And I've recreated the config folder, but carried over some settings that would be laborious to do over. I'll let you know if there's much difference.

[Wirezfree]

If you google for "Ubuntu 14.04 Libre Office very slow"
You get many hit's, inc:
- Disable Java in LO
- Clear recent docs
- delete a certain LO ./conf file


Plenty of things to check, and not related to Linux Lite.


GL

[paul1149]

Here's some good news. I went in to Options / Memory in LO and raised the RAM allotment. I had read that 120MB was the limit. I raised it substantially, and now LO uses up to 160MB  when taxed, and I'm finding the Replace operations are quite a bit faster, as is file loading. Not a total solution, but substantially better.

[paul1149]

To give you an example, when I was testing WPS Writer just before, I did a Replace of all paragraph endings in a 1.7mb file. It took maybe 45 mins, the app's display locked up (though I could minimize it via the Panel button), it ran 50% cpu, and when it came through it found some 47,000 hits.

[paul1149]

Normally everything is behaving very nicely. I have system resources open now and the biggest cpu eater is 'htop' at 3.3%, then several entries for Slimjet.

When I do the search the corresponding app jumps to the top, whether it's LO, WPS, or gedit. Normally LO only takes maybe 8% or less of cpu. Ram usage is never an issue.

[Wirezfree]

If you use System > Resource Usage
What is hogging CPU.?

[paul1149]

I'm giving WPS a try, and while it doesn't have Regex searches, it does have nice paragraph-finding wildcards. It's taking just as long as LO however.

[paul1149]

Hi Newtus,

Yes, I noticed that WPS is much more agile when it comes to the .docx format. I probably would have switched to WPS as my default prog, except it doesn't support macros or autocorrect, the latter of which I highly value. Not sure if it supports Regex searches either; I think not.

The file in question never was a .doc or .docx. It was plain text lifted off a web page (pdf), and on my second try it passed through a gedit save, which should have definitively wiped it of any extraneous formatting.

I think a major part of this is LO itself. There have been many complaints about memory usage. And my F/R operation was pulling in 20,000 hits, so it was a pretty big deal. Gedit, to my surprise, behaved even worse. Leafpad and Mousepad (which is really neat) did great, but don't have Regex searching. So I guess I'll wait and see what LO does about its problem.

BW,
Paul

[newtusmaximus]

I have had similar problems with LO when reading docx files created on a Windows machine.  However never noticed such problems with large files in "native" odt.  Could it be the "transforming" aspect from doc that is slowing things down??  i.e is the software converting the docx to odt before carrying out the task.?

I have tended to us WPS office for docx reading /editing as it seems to cope better than LO.  ??

[paul1149]

I tried the operation on the same file in LO on Win8.1 x64. While LO was sluggish in every way there with the 1.7MB file, the f/r operation went fairly smoothly. I suspect I have two programs that have problems doing large searches, and am not sure how Linux, or my install, fits into it.

[paul1149]

Hello gang,


Things have been very solid here for quite some time. But a problem that I had had before has cropped up again and I'd like to deal with it.


I use LibreOffice, and sometimes I will get larger files and reformat them. Typically I will do RegEx searches to find and replace blank lines and unwanted line endings.


Since Day One, Linux Lite 2.4 with its default LibreOffice would have problems doing this for files of any size - say, 1MB or more. CPU for LO will go to 50%, which doesn't seem too bad, but the display will partially freeze and the system will be largely or totally unusable.


Now I'm on LL 2.8 (x64, BTW) with LO 5.1.3 (x64 also), and the same thing is happening to a 1.7MB file. I split the file up into four files, and it did the same thing. So file size is only a minor factor.


This time I kept the files in .txt format, so I could work on them in gedit. To my surprise, the same system lockup is happening there as well, suggesting that this is a system problem. When I do this in gedit, the gedit process goes to 30% CPU, but another process called init goes to 35%, which is even worse than LO performed.


Any insight would be appreciated.