Hmm, my experimentation so far just shows LO consuming more and more memory to the point where my system becomes unresponsive requiring a force kill of the LO process.

I loaded LOdev master into Instruments.app and then followed memory allocations (until both LO and Insruments became unresponsive).

Once the document is loaded, transient memory allocation is running at 10 Gb.
I made a single digit change to one value without a comment in one cell, and then attempted a re-save.

Instruments shows that memory allocation goes through the roof, passing from 10Gb transient to 85Gb transient memory, at which point my whole system becomes unresponsive. Both LO and Instruments grind to a halt.

The memory guzzlers in this seem to be a combination of:

- rtl_UString_new_WithLength : only 1.5kb each, but a gazillion of them 

- rtl_Ustring_ImplAlloc(int) : quite a few of these too at 416 bytes a throw

This block is pointed to in strtmpl.cxx (1139-1157) 

IMPL_RTL_STRINGDATA* IMPL_RTL_STRINGNAME( ImplAlloc )( sal_Int32 nLen )
{
    IMPL_RTL_STRINGDATA * pData
        = (sal::static_int_cast< sal_uInt32 >(nLen)
           <= ((SAL_MAX_UINT32 - sizeof (IMPL_RTL_STRINGDATA))
               / sizeof (IMPL_RTL_STRCODE)))
        ? static_cast<IMPL_RTL_STRINGDATA *>(rtl_allocateString(
            sizeof (IMPL_RTL_STRINGDATA) + nLen * sizeof (IMPL_RTL_STRCODE)))
        : nullptr;




- I also see loads of calls to SfxItemSet::SfxItemSet(SfxItemSet const&), allegedly from itemset.cxx, but a search in itemset.cxx doesn't return any such line...

@Tor, I thought you could be interested in this issue...

About Telesto's initial description: What you describe isn't necessarily a bug. If the initial state is the Start Centre, it is very normal that after loading a document (for instance, a Writer one) and then closing that document, a lot of persistent data structures and code related to Writer functionality were constructed in and/or loaded into memory. Those don't go away even if you close the only Writer document open.

What would be a problem is if for each time you open the same document (preferably a simple one that doesn't do any weird things like run BASIC macros etc) and close it, the memory consumption increases a lot.

What Alex describes then sounds like a much more serious and different type of problem indeed.

Version: 25.2.3.2 (AARCH64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 12; OS: macOS 15.4.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Open test file: Memory goes from ~500 to ~760 MB
Press save: Memory goes to 1,1 GB
Close document: Memory goes down to ~700 MB

So the initial issue seems to be persisting.

Re-opening the file: back to 1,1 GB
Closing: back to ~700 MB

Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: cb149972d5fc82f3ca8009c3e51931c8d94ee664
CPU threads: 12; OS: macOS 15.4.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Sits at ~700 MB when opened and idle.
Open test file: Memory goes from ~700 to ~830 MB
Press save: Memory goes to 1,1 GB
Close document: Memory goes down to ~700 MB

I am not sure what is expected here and if the ~700 MB memory after closing the file are acceptable or not. It is noticeable that nightly build sits at higher memory use after opening right away. The drop there goes back to the initial value.

On the bright side, I don't see much lag in saving speed. It is taking 2-3 seconds. Either this is the improved Apple Silicon architecture or LibreOffice performance improved or a combination of both.

In light of comment 3, what comment 5 describes is normal and healthy behaviour, so let's close.