I get this:
Furthermore, with a large file, soffice.bin (LO’s executive) will consume unusual amount of memory and CPU cycle.
j8u131 fully ‘expired’ on august 2017, so there is a small chance that your Java itself is the culprit.
Hmm… maybe bigger than small. Thanks.
Since my LO 64-bit, I’ll have to get the 64-bit version too, right?
I download your LanguageTool latest daily builds - 4.2.5 but the document saving is very slow…
Problem is
An error has occurred in LanguageTool 4.1 (2018-03-27 11:22):
java.lang.NullPointerexception
Stacktrace:
java.lang.NullPointerexception…
LO 6, java jre 8.172 or 10.0
ubuntu 16.04 lts
That doesn’t seem to be a recent daily build, though. Could you make sure you’re using the daily build and also provide a screenshot of the error?
I installed the latest Java, then reinstalled LT4.1. No error msg, but LO crashed!
Upon restarting LO (which is automatic), the same error msg appeared. And as before, with a large file, soffice.bin (LO’s executive) will consume unusually high CPU cycle.
Am I the only one with the problem?
OK, I’ll try that and report back.
I’ve installed LanguageTool-20180528-snapshot and all is well. Thank you.
Same problem with me, but installing LT4.1 from Ubuntu snap does not integrate into LibreOffice.
Other solution?
Thanks
Sorry! I found this: [Index of /snapshots/]
Hopefully LO works now bugless…
Not quite. Now LO constantly consumes a full CPU core, sometimes more when I load a file with 60K words. Problem goes away when I disable LT ext. Help!
I’ve had LO on my own computer (a bit of an old workhorse that runs OO without complaint) for a few days and it had the same problem before LT was added.
So it’s possible that in your case LT only made the actual issue noticeable instead of causing it.
I disagree. The problem wasn’t there when I was using LT3.9, which I’m reverting to.
I did some test on my not very fast 2 core notebook. It is right, when LT runs it consumes nearly one core. I checked it for a 47K word (German) document. At default options (check 5 paragraphs before and after the actual - 11 times as much as for LT 3.9) it takes more then 5 minutes to do one check of the document, than the CPU load is reduced massively. If you set the check to only the actual paragraph the time to check reduce to 1 minute.
Another factor is the setting “check all paragraph again after every change”. This setting force LT to check the whole text again, when you change anything on the text. If you working on your text LT checks it permanently.
Both features gives better results by checking the text for rules that needs to check the text over the limits of one paragraph. But it cost computing power.
If you got older hardware or don’t like the effort you can change the settings to check only one paragraph and unset the “check all paragraph again after every change”. This should set the performance back to that of 3.9.
(Note: Another factor is the number of rules. If they had grown since 3.9, the time to check has grown too.)
While it’s sad if we have to turn off rules, I think it’s more important for LT to “just work” by default. If the current situation is a regression (performance-wise) against e.g. LT 3.9, we should change the defaults. The number of rules that consider more than just a sentence is very small, anyway.
Yes, I agree, we should change the defaults.
Maybe the next generation of hardware solves the problem and we can change the defaults back.
The default values are changed.
@dnaber Is there a place where the possibilities to change values are described? I think for some people it can be very interesting to change the values back to the last default. But most users don’t know the possibilities.
You mean a documentation? We can add something to the wiki, but 99% of the users won’t read that…