It will be hard to address this without sample file [https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission] There a plethora of possible causes. For example tables splitting wrongly to image anchor being at the wrong spot. Aside from the file format being of influence. 

The only advice is;
* resetting user profile
* using older version or trying a more recent version. 
* using alternative Office Suite
* trying the same file on a different system (including virtual machine)

----------
Yes, LibreOffice is kind of a minefield. There are risk using LibreOffice for complicated documents and delicate work. However that's my personal opinion. And regular updates doesn't mean that incremental improvement. Old problems get fix, new issues are introduced. If LibreOffice being the proper tool surely depends on use-case. Apparently it works for majority of the users..

hello Telesto, nice to see you alive and active ...  
  
> It will be hard to address this without sample file  
Yes, I know, but I don't see the point in investigating, providing  
better info, with the only reaction being asked two years later  
to check if the issue vanished in the meantime. The post is more a  
warning to users and a demand to programmers ... try to produce  
stable code.  
  
> There a plethora of possible causes.    
Yes, and each "I think it helps" instable patch doubles them.  

> For
> example tables splitting wrongly to image anchor being at the wrong spot.
> Aside from the file format being of influence.  
All these shouldn't come up in stable programs, and we can't blame  
innocent unwitting users about it.  
  
> The only advice is;
> * resetting user profile
> * using older version or trying a more recent version. 
> * using alternative Office Suite
> * trying the same file on a different system (including virtual machine)  
And all that is quite poor "poking in the fog" ...  
  
> ----------
> Yes, LibreOffice is kind of a minefield. There are risk using LibreOffice
> for complicated documents and delicate work. However that's my personal
> opinion. And regular updates doesn't mean that incremental improvement. Old
> problems get fix, new issues are introduced. If LibreOffice being the proper
> tool surely depends on use-case. Apparently it works for majority of the
> users..  
Yes, it's not useless, however a better coding discipline and some rework  
might be beneficial.  
  
An idea to help people who have saved older states ... provide an option for  
side by side compare of the old and new version, with highlighting differences   and easy transfer would save a lot of time in the experimenting you proposed.  
  
Just my two cents ...

(In reply to b. from comment #2)
> Yes, it's not useless, however a better coding discipline and some rework  
> might be beneficial.  

Not sure if it's coding discipline. Say: table layout isn't static, it's calculated on the fly on each edit. And there plethora of variables. Embedded tables, with embedded tables again. Merged rows, merged columns. Different font sizes. 

So bugs are supposed to happen. It's highly complex. 

Each time the 'refactor' certain area to accommodate today's need, new bugs get introduced. From stuff that got overlooked too, old code simple working by coincidence, to performance issues with compatibility layers, bugs being masked by certain behaviour

Their is plethora of reasons
A) primary lack of resources: developers (enough bugs in the bug tracker)  So some developer will take up the task to refactor area XYZ. However gets 'flooded' by the fall-out. Unable to address it all alone (feeling overwhelmed). Others are simply starts collecting the bugs, so he/she someday able to fix those bugs at once when 'familiar' again with the code and when he she has time.
B) Lack of testers
C) fixed release schedule. Each time presenting something 'new'. With changes made last minute; with no time to check for side-effects. Holding off has no purpose either: as stated above: lack of testers. Nor developers to solve them.
D) Need to compete with competitors. Adding half-baked features to be able to compete. However issues aren't ironed out by lack of resources to fix them (and/or testers to find theme before release)

At the developer side
A) Volunteering developers have only so many free hours and needs to be 'fun'. Aside from personal life changes. Getting married, having kids etc. The move on 
B) Paid developers are able to spend more hours. However the must be feel up to the task; the also need enjoy working on the code. Coding can be terrible frustrating; whack a mole

Ideally there is an 'army' of lets say 30/40 full time paid developers working 5 day's a week improving the code (based on the size of the project). With a support team in the background. In reality it's more of 5-10 (part-time) developers, most hired by an eco-system partner getting X time from the employer to work on LibreOffice at choice or getting a designed task (or something like that). So couple of weeks nothing, couple of changes, and back to radio silence (busy with other tasks).

The whole project is quite understaffed and/or overambitious, IMHO. The result is pretty decent seen from resource perspective. However not the quality product, you might expect. And the general quality isn't improving incrementally over time either: One bug being replaced by another on in the same of different area. Sometimes I get the feeling (subjective) it's getting worse: more large refactors where done, without addressing the loose ends. 
Ok, by some measure it might be improved: number of crashes likely less compared 5 years ago; in my perception at least.

hello @ Telesto,  
  
you are quite nicely describing a project that has become bogged down in mud and suffers from more will than skill ...  
  
There is another way, look at code by Dan Bernstein ( qmail ) or Miguel de Icaza ( midnight commander, gnumeric ) ...  
  
Or try to get access to Volker Birk's talk "Software Engineering".  
  
More manpower mostly improves confusion, better quality is the way to go ...  
once lost it's hard to recover ...  bin-FP calculations contribute a lot.

(In reply to b. from comment #4)
> hello @ Telesto,  
>   
> you are quite nicely describing a project that has become bogged down in mud
> and suffers from more will than skill ...  

* Bogged down sure. 
* More will than skill. No idea, the experienced developers appear pretty skilled in my perception, but well I have no coding experience. So looks like magic anyhow :-)

The number of active experienced developers - familiar with certain parts of the code - shrinking is less helpful. Lots of legacy code (without much documentation) doesn't help either. 
   
> There is another way, look at code by Dan Bernstein ( qmail ) or Miguel de
> Icaza ( midnight commander, gnumeric ) ...  
>   
> Or try to get access to Volker Birk's talk "Software Engineering".  

Probably :-). I'm not a big reader myself. And not too familiar with the developer world. LibreOffice suite surely quite a big project with the various applications. Gnumeric is way more focused


The 'can do' mentality doesn't help either. If you ask (pay) we realize scope creep. So if some company XYZ wants to use LibreOffice for simple modifications to PDF document, someone will implements a PDF import filter. The implementation might have limitations and quirks, but it's good enough for XYZ. Now people can open PDF's complains arrive regarding the limitations. Next step is a discussion of becoming a full-fledged PDF-editor...
   
> More manpower mostly improves confusion, better quality is the way to go ...
There is an optimum, sure. However there are enough area's which could use dedicated developer for quite some time. There are all sorts of independent components and layers. Import filter/Export filter for various file formats. VCL rendering; Accessibility. The various components (Writer/Calc/Draw/Impress/Base/Math). Calc/Draw/Impress/Base/Math are getting the bare minimum attention. 

The question is more who decides about what the developer should address (or not). There is no general direction. There is no focus/prioritization. Only more and less vocal people and people with little more power compared to others (Board Members) 

TDF Budget might be spend on reviving Base (niche product, and unmaintained for years), I read. Say this entails hiring a dedicated developer for 18 months; At the end focus will shift again. Base developer gets fired or re-assigned, because of other priorities (Hello Writer/Calc). So we gonna improve 'horrible shape' to ideally good. And letting it decay again to mediocre or bad, I fear. The old users of Base moved on; I guess. So we need to create the userbase for Base again? And when new users do arrive it's probably 'unsupported' again; hello bugs.. 

> once lost it's hard to recover ...  bin-FP calculations contribute a lot.
The quality issue where already present since the fork to LibreOffice, if you ask me. 

"bin-FP calculations contribute a lot." 
To cryptical for me. I suppose you're referring to Calc and something with floating points?

It looks as if ... after deleting the notes, and having writer and  
the document open in background for several hours! continuously  
stressing my fan ... the issue vanished and I'm back to normal  
performance, normal CPU load and silence by a slow fan.  
  
Don't blame me for reporting instable or hard to reproduce bugs,  
instead think to design LO and writer programming to produce stable  
or - better - no bugs.

It looks as if ... since some time I'm getting more spam  
from this site than anything useful ... see above 2 comments.  
  
On the one hand, this is an appropriate fate for a bug tracker / community that is overwhelmed with dealing with bugs and has specialized in “managing” them for years, on the other hand, it's annoying.  
It would make sense if “the administrators” made the effort to put the first e.g. 5 comments of new contributors under moderator review, and simply kick out spam instead of setting it to “hidden”. Also to set those commentors into some honeypot.

happened again, Fan active, 100% CPU load by soffice.bin,  
... Repagination ...  same document, this time without any  
"Notes".  :-(  
  
Is there any method to somehow diagnose what triggers this  
behavior?  
  
Are more than 65535 words critical? Shortly crossed that  
limit.  
  
In this case it lasted 3 hours of waiting until the high  
CPU load stopped.

Hello b,

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. You can create a similar document with copy paste of some random text.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public; remove any sensitive information before attaching it. 
See <https://wiki.documentfoundation.org/QA/FAQ#sanitize> for help on how to do so.)

kidding?  
  
I shall change a medium sized document with 180 pages of text, using 4 different fonts in 6 different sizes,  
3 color formattings, 6 background formattings, headers, footers,  
logos, 3 indexes, 19 pictures, 13 tables, 83 footnotes, 48 endnotes,  
32 set references, unknown amounts of referrers to them,  
~200 hyperlinks and ...  
to randomity, then hope that an instable issue stable re-appears in an  
instable program, attach it and then wait about  
a year to receive a comment asking me to check if the bug  
vanished by itself ... ??? no way.  
  
An alternate proposal: construct a test document "chaos.odt", define  
amounts for pages, images, tables, formats, ... which shall be assured  
safely usable in LO writer, make the document with ten times that amounts,  
and look if and where issues pop up. Then dig down what and why.  
  
E.g. allowed are 1000 pages, 1000 images, 1000 tables, 100 formats, 1000 notes  
... make the test document with 10 000 pages, 10 000 images ...  
Once it works communicate the small limits to the users.  
  
Benefit: that is one time work by experts, and will lead to results,  
much better than 1000 of times work by users which then is ignored.  
  
best ...  :-)

observation, don't know if it helps ...  
  
leaving the document open at first page overnight  
-> in the morning still 100% CPU load.  
  
scrolling two pages down  
-> CPU load reduces to normal, ~0.5% in this case.

add. observation:  
  
at some places, think about 50% of document space,  
the "focus marking" light grey-blue background highlighting  
searched or selected text, flashes on/off in short erratic  
sequence.

Is it possible that the slowdown is related to the  
activation of “Save AutoRecovery Information every:”?  
  
I had set it to 10 minutes, and the slowdowns seem  
to be lessened when it is deactivated. After  
reactivation, the program freezes for about 1 minute  
every 10 minutes and “repagination” occurs.

(In reply to b. from comment #15)
> Is it possible that the slowdown is related to the  
> activation of “Save AutoRecovery Information every:”?  
>   
> I had set it to 10 minutes, and the slowdowns seem  
> to be lessened when it is deactivated. After  
> reactivation, the program freezes for about 1 minute  
> every 10 minutes and “repagination” occurs.

Well it's possible. Although I expect some overlap. So constant layout loop in the background. Exacerbated by auto-save

A performance profile would give some more insights what's going on. There multiple tools available for CPU profiling on Linux: perf_events, DTrace, SystemTap, or ktap.

I have no experience with those tools.

Created attachment 202185 [details]
A “flamegraph” recorded during backup in writer.

Attached is a "flamegraph", my first flamegraph,  
recorded during two manually triggered slow backups  
with "repagination" in writer.  
  
With its high peak, it looks a bit unusual to me,  
a long chain of nested calls? And unfortunately,  
it contains a lot of "unknown". Perhaps experts  
can read some clue causes from this, or maybe  
someone can advise me on how to resolve the  
"unknowns".  
  
Local compilation with debug info? How?

add. observation: after another overnight "stay open" of  
two similar documents, the origin and a copy with some  
small edits in both of them, the origin which was the active  
window reproducibly saved in few seconds with repagination  
only once passing the screen.  
  
The copy which was open however not active overnight takes  
about 40 seconds for save, with one pass of repagination  
long stall at about 80% finished.  
  
After having tried the copy the pest re-infected the origin,  
now about 45 seconds for save, however also now with one  
pass of repagination, which before had been multiple passes.  
  
After close and re-open of writer, and opening the original  
document saving takes ~60 seconds and about 15 runs of  
repagination. Confusing.

@Ilmari
Any advice how to avoid "unknowns" in a flamegraph?

(In reply to Telesto from comment #19)
> @Ilmari
> Any advice how to avoid "unknowns" in a flamegraph?

I was just wondering about the same thing the other day. I have to ask others.

(In reply to Buovjaga from comment #20)
> (In reply to Telesto from comment #19)
> > @Ilmari
> > Any advice how to avoid "unknowns" in a flamegraph?
> 
> I was just wondering about the same thing the other day. I have to ask
> others.

I discussed it in the dev chat. In my case, this might be the answer: "we might not be passing down flags properly into 3rd party libs at all times. or its a system lib."

In b.'s case, it can be a lack of symbols. There are no pre-built releases suitable for perf tracing, so one would have to do an own build with --enable-symbols and not any debug/dbgutil options.

Cruel I.) the auto-save backups in Writer also block a parallel Calc process, even if it was started independently from another terminal. 
  
Cruel II.) I tried to identify any weak or faulty areas by deleting chapter by chapter, with inconsistent results. Such as:  
- deleting chapter 2, savings quick,  
- reinserting chapter 2 -> savings again very slow,  
- removing it again -> savings still very slow ...

the following is widely reproducible:  
open program and document: "normal" CPU load,  
  
save by ctrl-s or auto save of recovery information -> high CPU load,  
stays high after save is completed,  
scrolling up some pages ( pgUp ) -> CPU load reduced to normal,  
  
save by ctrl-s or auto save of recovery information -> high CPU load,  
stays high after save is completed,  
scrolling up some pages ( pgUp ) -> CPU load reduced to normal,  
  
save by ctrl-s or auto save of recovery information -> high CPU load,  
stays high after save is completed,  
scrolling up some pages ( pgUp ) -> CPU load reduced to normal,  
  
if at start of document when saving than to reduce CPU load scroll some  
pages down and the up again,

Created attachment 202425 [details]
A part of a document showing blocked scrolling.

Additional observation:  
  
In a poor man's attempt to boil down I splitted the document in pieces.  
The solo parts up yet don't show the issue, re-combining pages 1_50 with  
51_76 leads to one point where scrolling up with <page-up> is blocked.  
On page 67 the cursor jumps from the start of a line below a table with  
a "caption below", to the start of that caption, and on next <page-up>  
back to the start of the line below.  
  
After saving that document the "soffice 100 percent CPU load issue" and  
multiple runs of repaginations re-appears. I assume something like  
ill-chaining of objects, "loop"?  
  
Any clue to pull from that? Do we have a "document sanity checker"? 
  
I attach a document snippet which - here - shows the blocking, not  
the load after I shrinked it for publishing, not in every attempt  
but in many. Funnily it kept pages 3 .. 10 when deleting the content  
... ???  
  
As the issue is erratic, a good reproducer is to click on the table  
at top of page two, and then scroll up with pg-up. Get the cursor  
toggeling between before "Figure 2." and before "Source".

Further tried to disassemble the first page in single elements as  
"unformatted", delete them from the text and re-construct the page.  
Same position to hang in scrolling.  
  
Found a similar complaint in "ask", document becoming unstable once  
inserted picture not fitting until end of page.  
  
XML document checkers complain about:  

The element type "inttypes.h" must be terminated by the matching end-tag "". 
The element type "inttypes.h" must be terminated by the matching end-tag "</inttypes.h>".
The Element Type "inttypes.h" Must Be Terminated By The Matching End-tag "</inttypes.h>"., Line '241', Column '3'.
The Element Type "inttypes.h" Must Be Terminated By The Matching End-tag "</inttypes.h>".  
  
Not allowed to put program code into a writer document?

Further observation:  
  
After activating <Edit - Track Changes - Record> the "CPU load  
/ repagination / slow save" issue vanished. If it's relevant:  
Track Changes had been used some time before, and then was  
switched off.  
  
The "stuck in pg-up" issues stayed, thus likely not related.

FWIW, I found bug 168074 by toying around a bit with your file; probably unrelated though

Confirmation, "slow issue" is gone and didn't - yet - re-appear,  
so what remains is that in whatever circumstances a document can  
switch into a state where saving it causes lot's of repaginations,  
and then keeps something - looping? - active causing high CPU load.  
  
That's likely somehow related to some setting / variable / condition  
of "track changes", however that's not a single point issue.  
I tested with an old version, it's still affected, so it's likely  
a document issues and not installation, OS or "user profile",  
however the old document kept "ill" status over multiple switching  
tracking on and off, "record", "show" and "manage", also save and  
reload.  
  
Either I failed in spotting the relation tracking - slow, or it's  
a multi-factorial issue.

additional observation: both idiosyncrasies ( slow and stuck in scrolling )  
re-appeared, stuck in scrolling at another picture, and unveiled another  
issue in comparing password protected documents ( workaround: un-protect,  
then compare ).  
  
The re-appearance was after I undid some changes I had made to avoid  
inserted images crossing page breaks, I did read somewhere about that as  
possible cause, however not instantly and I made other changes as well.  
  
In first attempts track changes didn't heal, so I choosed to transfer  
the changes, doing it automatically it transferred the issue as well,  
piece by piece manual copy kept the document "issue free".  
  
So I have a document which I alas can't share as of now, however if  
someone has a suggestion what to test / check / change I can do.  i

Created attachment 203038 [details]
affected document

Just in case it helps ... attachement.  
  
The bug stroke again, having one clear position in a document where inserting text and by thus producing a newline changed: 
 
without: CPU load ~5%, saving the file 5 seconds, 
with: CPU load ~100%, saving the file about a minute. 
 
reproducible, reversible, save-load persistent ... 
 
Alas in obfuscating the literals change width, the paragraphs change length, all in document changes position. In that the option to go back to "sane" is lost. 
 
Thus the attachement is "ill", you may like to try to change by deleting text before "critical!!!!", if you assume the issue caused by something behind it being pushed down by inserting. 
 
( I can _assume_ some position calculation problem near "An Emacs-Cairo Scrolling Bug" https://inria.hal.science/hal-04566768/document , which I consider more a general math problem than special "floating-point", however demonstrating that position calculations with approximated operands and more or less meaningful corrections do often hold .. often, not always, but that's only a newbíes assumption in his limited horizon. )

Test document is quite a nice reproducer.
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6f68c46d0aa5fe872de0dec8777d35ff91886043
CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

Some impression what's going on:

OutputDevice::InitFont
OutputDevice::GetTextHeight
SwFormatCharFormat::ItemType
SwTextFormatColl::IsInSwFntCache
SwTextSizeInfo::SwTextSizeInfo
SwDrawTextInfo::SetSpace
SfxEnumItem<enum SwLineBreakClear>::GetValue
SwTextFrame::GetAdditionalFirstLineOffset
SwTextFrame::GetAdditionalFirstLineOffset
SwTextFrame::FormatLine
SwTextFrame::Format_
SwTextFrame::FormatImpl
SwTextFrame::Format
SwContentFrame::MakeAll
SwTabFrame::IsComplete
SwPageFrame::PrepareFooter
SwPageFrame::PrepareFooter
SwPageFrame::PrepareFooter
SwPageFrame::PrepareFooter
SwPageFrame::PrepareFooter
SwViewShell::LayoutIdle
SwBreakIt::GetForbidden
Scheduler::CallbackTaskScheduling

  
thanks for watching,  
  
> Test document is quite a nice reproducer.  
  
So there is hope the issue can be analysed, understood and eliminated?  
  
The rest of your comment is "chinese" to me, however shows LO code is not very simple / easy ...  
  
:-)

Also in
Version: 7.5.6.0.0+ (X86_64) / LibreOffice Community
Build ID: f0e825382a76d685998be702ed551a00b73476a5
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

also with
Version: 7.3.8.0.0+ (x64) / LibreOffice Community
Build ID: e1ad83ddb2f39419fb5d7c69eba51e2b9f49c788
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

No noticeable looping idle job 
Version: 7.2.8.0.0+ (x64) / LibreOffice Community
Build ID: ffa09959edd087794b1f2fe6b9b6faac484ef74b
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

See also:  
  
https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_status=NEEDINFO&component=Writer&list_id=1896963&order=resolution%2Ccomponent%2Cpriority%2Cbug_severity&product=LibreOffice&query_format=advanced&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED&resolution=NOTABUG&resolution=NOTOURBUG&resolution=INSUFFICIENTDATA&short_desc=slow&short_desc_type=allwordssubstr

(In reply to b. from comment #32)
> The rest of your comment is "chinese" to me, however shows LO code is not
> very simple / easy ...  

No expert either. So interpretation by a novice. It's (combined) call stack from +/-10 seconds of execution. I read it bottom up. Bottom of the list is 'who' requested a task top of the list who executes to most  specialized task (everything in between are all the instances who delegate some special task to 'someone' else as pre-requiste). My guesswork: So there is a 'Scheduler' who gives a task to: SwBreakIt::GetForbidden. Sw in 'SwBreakIt' means StarWriter (StarOffice). BreakIt, apparently 'splits something (I guess). But some splits are not allowed? It's an idle job (so background process). It's somehow related to rendering a 'Footer' (PrepareFooter). Next it's FormatLine (of text, I guess) with some some defined FirstLineOffset. (GetAdditionalFirstLineOffset). It needs to info TextSize info (width/height). Which request "TextHeight" from a Font

Apparently it's doing that over and over for the same line of text. Or requests Height for multiple lines of text, but can't find place to split the page without an exit in the loop it keeps retrying (infinite loop). A simple perf trace doesn't tell. It could even be some 'invalid' text height, throwing the whole thing off-track

You need to walk through all the steps one by one to see what's going wrong (so wo gives which takes, and what the result is. And possibly add debug code to see what's actually happening. 

A bibisect shows by which commit the problem got introduced. However this can be the 'direct' cause mistake (wrong fix). A missed case (incomplete fix). Or it might simply exposing pre-existing..

  
Not a pro in LO code internals ... it's either not "infinite loop" as it finishes after some time, or there is some sort of watchdog breaking infinity.  
  
It's for sure something in the structure of the document, however that shouldn't happen with a clear concept what to place where and what to account for space.  
  
Of course there can be difficult cases where it's neccessary to relocate something due to space overstretch ( or assumed overstretch reg. bin-FP imprecision ), and then differently evaluate the free space available and think it could be placed back or similar ... however 1. a clear concept how to handele space, and 2. a sensitive use of bin-FP math should avoid such ...  
  
It's some sort of general problem of LO as patchworked software, that after some time it's impossible to get all patches to fit together, as well as removing one or some ...

  
As I _assume_ it will take some time until a dev has time to analyse the already bibisected issue ...  
  
and as I step by step become a pro in workarounds ...  
  
If you stumble into this issue,  
  
1. Keep the file open and save it with a new name, DO NOT close it before you are fully finished with repair, save again with another new name to work with, if it is encrypted make the copy without password. Ver. BAD in the following.  
  
2. Check through the undo steps, saving the file to a third temporary name, with luck you find a step / version which saves quick, heals the issue.  
  
3. If not successful check for available older copies or backups, remember to also check for *.bak versions, also in your user directory / profile. Before accessing any of them make a new separate backup copy and only work with these copies. Check if any of them is ok, saves fast, then save unencrypted.    
  
4. If no success in 2. or 3. make a new file. The file from step 2., 3. or 4. is named as GOOD below.  
  
5. Now you have two unencrypted files, one BAD and one GOOD.  
  
6. From inside GOOD select Edit - Track Changes - Compare Document... , 
select the newer one - BAD - with issue as compare target,  
  
7. you get a list of differences, evtl. you need to open Edit - Track Changes - Manage,  
  
8. the differences are in the logic as if the GOOD file had the content of the BAD file and what needs to be changed to go back to it's old content. By !rejecting! the proposed changes the newer content is pulled into the old file. 
  
9. When finished try how well the new version works. If not retry with other versions / variations.  
  
10. In the logic of the patchworked LO design ... evtl. a dev. would like to implement a CPU-load-checker, and ring an alarm whenever writer has high CPU load for some time? And:  
  
11. Like to implement something near the recipe above as "repair-attempt" option?  
  
12. Evtl. with an option to check for differences and mail them to LO for analysis?  
  
It shouldn't stay like it is ...

Hint on the root: I did read somewhere in a similar report? about table splitting being evil, had a new occurence of "save slow, high load" after inserting a new table - and some other changes, in piece by piece repair I could identify one point: 

inserting the part with the new table causes slow save, changing it's properties to not splitting over page breaks by unticking the option in it's properties heals. 
 
HTH

Bisected to:
/win64-7.3 ((3dfb0b357...)|BISECTING)
$ git bisect good a67c21c555a05f7015f2f5a533dabedca840e620 is the first bad commit
commit a67c21c555a05f7015f2f5a533dabedca840e620
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Tue Mar 15 10:08:03 2022 -0700

    source 3d8533cb894614394f1ecf05b3d6dc60f3bf6dd6

    source 3d8533cb894614394f1ecf05b3d6dc60f3bf6dd6

 instdir/program/setup.ini   |   2 +-
 instdir/program/swlo.dll    | Bin 16889344 -> 16889344 bytes
 instdir/program/version.ini |   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)

-----commit message -----
tdf#139687 sw: invalidate text frame in footnote when moving it

The problem (which only reproduces here on copy/paste with
SAL_USE_VCLPLUGIN=kf5, not with gtk3) is that on SwTextFrame 2638 in a
footnote on page 19 containing "Saeed, 100–101." there should be a top
margin of 0 but it's actually 144.

The footnote was initially created on a previous page with another
footnote with SwTextFrame 2635 before it, that's how it got this top
margin.

Invalidate the print area in SwFootnoteFrame::Paste(), which is called
when the footnote is moved to a different container.

(somehow regression from commit 723728cd358693b8f4bc9d913541aa4479f2bd48)

hi,  
  
nice to see progress,  
  
a question: is that a fault of me, not allowed to move around footnotes?  
  
And a warning: my above contributed tips / workarounds have weaknesses / suffer from other weaknesses in writer, somewhere in copying around, comparing documents and the like you may loose headers and footers, and also somewhere you may loose textboxes, and evtl. more which I didn't yet find. So always keep the old versions, just in case of ...