[Libreoffice-bugs] [Bug 129101] New: Image handling and memory usage horrible

[bugzilla-daemon at bugs.documentfoundation.org]

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 at lists.freedesktop.org
          Reporter: roland at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191129/cda155d5/attachment-0001.html>