https://bugs.documentfoundation.org/show_bug.cgi?id=129101
Bug ID: 129101
Summary: Image handling and memory usage horrible
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: rol...@logikalsolutions.com
I have seen this on both Windows 10 and
Version: 6.0.7.3
Build ID: 1:6.0.7-0ubuntu0.18.04.10
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); Calc: group
I'm currently writing "The Minimum You Need to Know About the Phallus of AGILE"
which is tipping the scales around 600 pages. There are many images. I have
tried just about every tweak I can find online for improving performance.
Nothing works.
When making a change high up in the document file, one which causes a page
break type shuffle, something where LO has to move pictures around found later
in the document file, machine drops to a crawl. It can take close to 10 minutes
before LO responds to keyboard. The only work around is to exit LO and reopen
the document.
My gut combined with 30 years of IT tells me this is a Java problem.
Operating System: KDE neon 5.17
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.0.0-36-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz
Memory: 23.3 GiB of RAM
As you can see this is a 6th gen i7 having 24 Gig of physical RAM. When I pull
up Kinfocenter, I see there is 18 Gig free while the document is desperately
attempting to re-adjust pagination. Word processors using natively compiled
3GLs don't have this problem because they can consume as much RAM as they need.
Java and other VM based interpreted languages are at the mercy of what the VM
allows. Adding insult to injury garbage collection doesn't happen until the VM
decides it is idle. It can't get idle when it is desperately trying to
reallocate things.
The only "fix" I can see is to purge 100% of Java from the project. The VM has
had over a decade and it still cannot grow to consume as much RAM as is
available. It's like it is still restricted to a 32-bit address space.
roland@roland-HP-EliteDesk-800-G2-SFF:~$ java -XX:+PrintFlagsFinal -version |
grep -iE 'HeapSize|PermSize|ThreadStackSize'
intx CompilerThreadStackSize = 1024
{pd product} {default}
size_t ErgoHeapSizeLimit = 0
{product} {default}
size_t HeapSizePerGCThread = 43620760
{product} {default}
size_t InitialHeapSize = 392167424
{product} {ergonomic}
size_t LargePageHeapSizeThreshold = 134217728
{product} {default}
size_t MaxHeapSize = 6264193024
{product} {ergonomic}
uintx NonNMethodCodeHeapSize = 5835340
{pd product} {ergonomic}
uintx NonProfiledCodeHeapSize = 122911450
{pd product} {ergonomic}
uintx ProfiledCodeHeapSize = 122911450
{pd product} {ergonomic}
intx ThreadStackSize = 1024
{pd product} {default}
intx VMThreadStackSize = 1024
{pd product} {default}
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3)
OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3, mixed
mode, sharing)
I did find a pretty good post on determining Java settings.
https://www.mkyong.com/java/find-out-your-java-heap-memory-size/
It is where the above command came from.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
