Styles sidebar and TOC in document badly responsive

Writer 7.6 for Linux
working with master and sub-documents
sub-documents and master embed fonts, however only those in use.

Master includes up to seven subs, yet it starts with TOC.
TOC length is almost 2 pages.
In end region of master two blank text sections for further use.
The responsiveness is bad in at least two areas:
Sidebar with paragraph styles tab open
TOC context menu in master

Well, at least entering style edition dialog from menu Styles shows satisfying responsiveness.

In result it becomes very hard to modify the look of TOC.
I can’t see the computing resources (CPU, RAM) to be exhausted during problems are to be observed - there is lot of headroom, only CPU load shows occasional spikes up to 100%.

size on disk ?

in seconds ?

For all the font embedding is enabled, however an embedding only of those fonts in use (Noto Sans JK HR as the standard font). In one of my other yet recent questions I point out shortly the rationality behind the choice of this font.

$ ls -alh *.odt *.odm
... 72M  7. Apr 01:57 appendix.odt
... 72M  7. Apr 15:19 subd1.odt
... 74M  7. Apr 03:47 subd2.odt
... 72M  6. Apr 02:03 subd3.odt
... 74M  7. Apr 12:57 subd5.odt
... 72M  5. Apr 22:46 subd6.odt
... 72M  6. Apr 22:57 subd4.odt
... 74M  7. Apr 15:20 master01.odm

Time behavior: when the situation escalates the context menu in sidebar and in TOC in document pops never up. But it starts with couple of seconds (4, 5 or so) of wait time.
The observation made after OP: when it really escalates the whole GUI gets stuck and only a tear-down of open windows helps to recover. So far it occurred 3 times. Before the start of my efforts to make all them to one work (.odm) the problem was not observed.

Can embedding of fonts in use be dropped if document is planned to be distributed to reader only exported to PDF?
I have the feeling font embedding increased save to disk time remarkably.

Font embedding in .odt is unnecessary if you are going to export to pdf. As I understand it, you enabled it to use the same font on another computer rather than installing the font there. I think Noto Sans CJK HK, which is intended for Chinese language, will be large.

Also, if you didn’t limit it to fonts in the document, then you will be embedding every font installed on the computer which could be tens of megabytes unnecessarily added to the file.

Hi,
Unfortunately the problems seem to be slowly back.
These are current document settings regarding font embedding
43
If to uncheck all three checked on picture there are no changes in file size.
In the meantime, means since my last reporting, all .odt have been copied to one single .odt. I work on latter one since eight hours ago. Its current size 2,09MB.
The decrease of responsiveness is again observable. When it starts the wait time for GUI reaction are numerous seconds. Scrolling paging is not smooth.
Regarding objects embedded there are 6 svg pictures - no links, 18 LO Math formulas, 36 fields, 34 internal references. Remaining content is Writer native.
Out of 10.8 GB system memory the 48% are in use.

Helps closing LO, Opera browser, Chromium browser, reopening .odt. Idk how durable this effect will be.

When you export to pdf, the default is to embed fonts then.

What is the benefit of embedding fonts in the odt now?

BTW I looked at an image of the Noto Sans HK font and it looks quite close to Yu Gothic Semibold which I think might be a Microsoft font. Noto Sans is not too different. Mulish Medium font might work too.

Thanks for hints. It’s Linux, Microsoft fonts are not available. I didn’t also purchase a license for their fonts.

Reason is only one and quite simple, I see no difference in file size between embedding enabled and disabled. No more reasons.

One more background detail, no idea if it matters in this case: up to 10 document versions saved in .odt.