I was level 63 on first playthrough with just under 500hrs gametime when the freezes /lag spikes first occurred out of nowhere. Having no knowledge of the "bloated save file", I spent nearly 3 weeks troubleshooting (setting changes and reductions, mod removals, driver reverts, hardware tests, on and on and on) all the way to a reinstall before finally discovering the bloated save file was the core cause of my sudden game issues.
Since this point, I've tried removing mods on original playthrough, waiting 30days, added debloat mods (Mart's debloat and possessive corpses (not at the same time)) but yet have had no success in reducing the save file sizes in order to continue that original playthrough without these bloated symptoms.
I started a new playthrough but would still prefer to continue the original with a solution in hand.

Has anyone been able to correct and remove the effects of the bloated saves and continue their active playthrough without having to start a new game?? If so, how? Any suggestions besides the efforts already mentioned..?

i keep hearing about bloated save files. im over 300 hrs, and my saves are just over 15mb(with game done). I havent noticed any trouble. i saw talk on here of a mod that reduces the size?

Yeah my files held steady at around 15mb as well for a long time, but one day just started increasing incrementally 4-5MB every save till the freezes kicked in at about 65MB.
There are two mods, that I know of, that address the contributing elements of bloating saves. The two mods are Mart's debloater, and Possessive corpses. I've tried both, but I believe they are more effective in preventing saves from bloating. Opposed to reducing an already bloated save.

Bump..
I'd also like to dynovision to my list

Dynavision has problems with leaving script traces even after you remove it. The bloated save file that I have, had this mod installed and re-installed a couple of times. I don't have proof but if you search through the official thread of the mod, a user posted their own papyrus log. The issue was noted on the Dynavision thread in Nexus and the author is looking into it.

Since I did a clean reinstall of my game, and I mindlessly didn't keep my bloated save file. I'm gonna give the list of lite to > script heavy mods that I had when the problem started snow balling.

-Skyrim Monster Mod
-Deadly Dragons + DD Textures
-Duel
-Occupy Skyrim
-Total Realism Basic Needs
-Advance Kill Moves
-Dovahkin relaxes too
-Multi Marriage/Followers

And also during that timespan, I uninstalled and reinstalled some mods one of them is Dynavision, Deadly Dragons, and Total Realism.
This is my mod list activated during that time:

Stilllogicz also posted his mod list on that thread;

Also note that I had patch 1.5 when the save bloat started. And I didn't even put much play time into those saves. It just started bloating on such a short notice.

I'm trying to recreate the problem but I'm running everything on Skyrim version 1.4.27. The reason I'm doing this is because I had no problems with all of those mods before I updated to patch 1.5, and I'm trying to prove it by testing each one at a time on a clean save. I will also give them enough play time to develop inside the game by playing like I normally did when the problem started happening. After I go through those heavy mods, then maybe I'll do the same with Skyrim patch 1.5.

So far I have Skyrim Monster Mod installed, and I'm travelling and exploring new areas around Skyrim. Bumping into new creatures every minute or so, so there will be a lot of dead bodies littered around. I'm saving frequently and I'm noticing a few reasonable jumps on kb, +200kb every time I run, and expand the map by exploring. I think its reasonable jump.. and also note that its not a constant increase. It also goes down by 100kb when enough time has pass by.

I do use Dynavision, UFO - Ultimate Followers, Duel Combat Realism, Deadly Dragons + Textures, hardcoe Skyrim - Needs like Sleeping and Nourishment, Dovahkin Relax Too, used Killmoves Plus, and I set my Timescale to about 5. All this...strange coincidence, maybe its corelated to bloating...

@Scepth. I too was using 1.4.27. To start new game and saves remained under 5MB
Last night updated 1.5.26 to continue testing as well.
Are you currently using either of the anti-bloat mods while during your testing?
Ie. MARTS DEBLOATIFIER or POSSESSIVE CORPSES

Aye, since I'm running Skyrim Monster mod at the moment I'm using possessive corpses, Skyrim 1 day dead body remover, and Skyrim 10-dead body limiter (a mod that should only allow 10 dead bodies present in a cell).

Those mods might be voiding the fact that I should be doing this on a clean install, but I figure they shouldn't harm the result. Besides I don't think its dead bodies that are bloating up the game. My assumptions are scripts and mods clashing together.

Currently level 15 with all of my mods from the previous list that Scepth linked and my filed is fluctuating between 3.8 and 4.2. Only difference is I'm using possessive corpses now.

At the moment I'm running my game now with graphic enhancement mods, texture and mesh replacers, hair mods, skin/body mods, weapons and armor mods. Plus Skyrim Monster Mod and Legendary Dragon Lore (An alternative to deadly dragons). I'm not experiencing any abnormal save files so..

I'm gonna go on ahead and jump the ship by installing Dynavision playing, uninstalling it, pass time, then re-installing it again. And see if I get those significant mb jumps.

I agree that the scripts left behind uninstalled and updated mods to be the main contributor to the bloats as well.
hence the reason I asked about the anti-bloat. I'm using marts debloatifier on this playthrough under the premise that leftover bodies and objects are not the core of this issue. Perhaps if anything, it may further delay the bloat.
My only concern is whether we can recreate the bloat on early and/or low level playthrough.
Like you mention, the bloat was sudden and significant when it first occur, but many many hours and saves have accrued prior the arrival of the symptoms. Although, I like your approach in actively changing mods and updates as you go.
You mention deadly dragons which has updates almost weekly it seems. As you test, are starting with current version moving forward, or did you start with older versions with the 1.4.27 update and updating steadily to current as you progress.
also, I too saw the topic/issue with dynavision you mentioned earlier, which what made me realize I needed to mention it as well. As you "jump ship" I'm most interested in your results from it. Good luck

If you mean am I testing with old versions of mods like deadly dragons then steadily moving up every update.. Then my answer would be no. I'm not testing in between versions or with newer versions, and I never updated any of my mods since the bloat started happening. Whatever mods I have saved in my Nexus Mod Manager folder, are the mods I had when the problem started to happen.

Having those big mods installed one at a time is not the issue it seems.

To me, the problem is starting to narrow down between Skyrim patch 1.5 and mods' compatibility with it. Add two more incompatible script heavy mods that can't exist together in that mix and we might be able to re create the bloat problem.

I'm still testing Dynavision. My hands are full at the moment since my computer/gaming time is limited today.

You know what? This is a shame for a big company like Bethesda to not forecast this, guys. And it is a pity to play a game, which should be extremely entertaining, checking all the time the saved game files to see if they are not bloated, everytime with a fear that some mod sometime will screw everything up. We should be only having fun. Thats the purpose of a game. Bethesda failed in this part, as it did in others of it's games, as I have heard.

I'll probably quit playing this great game, which I waited for sooo long time, and wasn't cheap, because of this problem. I'm not the type of person who create many characters to play with, I like to stick with one hero until the end of the story and let him overpowered.

Anyway, I'm STILL looking forward to a solution, maybe Bethesda pronounce itself about this absurd problem. Thanks that Diablo III will be launched next month.

I think the problem here are mods using registerforupdate instruction for sending updates to the onupdate event. It makes the onupdate event run each time the especified number of seconds (could be less than 1) passes. The problem is that if the onupdate event didn't have time to end before the new update happens, there will be two onupdate events running at the same time, and if a third update happens before both ends running the three events will be running at the same time.

This could happen because the script is too heavy for a too short timer or because the sheer amount of scripts running at the same time slows all scripts as a whole, while the timer will continue working at the same pace. The worst part, is that having more than one onupdate running at the same time slows the scripts further, so the problem grows exponentially. The more slow the scripts go, the more onupdate stacks and the more onupdate stacks the more the scripts are slowed.

This happening more ofthen since 1.5 could mean that the CPU time dedicated to scripts has been shorten in the last patch. So, as each script has less time to run, the chances of an onupdate not being able to end before the next one is created grows, and the very moment that happens, the problem explodes.

To avoid this. The only thing needed is to use registerforSINGLEupdate instead of registerforupdate, placing a new registerforSINGLEupdate as the last line of the onupdate instruction. The difference, is that this way the timer is set one single time and when the time expires, it calls for the onupdate event without a further loop. the update ends there. Then the onupdate is executed and only when it's finished it calls for a new timer loop.

So there is no way a new update can happen before the onupdate ends, as the new updating period is called only when the onupdate event has ended.

If you put it that way, its really beyond your average player's control when it comes to the issue. Its definitely something that mod authors should look at but Bethesda should take some responsibility on this, for allowing such a hole in their programming.

I have poor knowledge when it comes to scripting so the best I can do is salvage the mods I like and weed out the ones that are causing the problems so that I can still play my game.

There is one thing you could do. First you need a mod with really heavy scripting but not causing bloating on it's own. Have that mod unchecked, but check it for a single saved game, then uncheck again.

When want to verify if a mod can cause script savegame bloating, install it, check the huge scripted mod and load the test savegame, play for a few minutes and save (a new file, this is trash can fodder). If the new mod has a potential bloatting code, your new save should be really huge comparing to the previous one.

Now the trick lies in finding a mod with heavy enough scripts (you can use various mods for this purpose, but you need to check and uncheck them all depending if you want to test a mod or play the game).

@Amgepo. Is the onupdate instruction you are referring to written in to the game's scripting language or is that on a per mod basis?

This is also foreign territory for me as well, but I'm desperately trying to better educate myself on the inner workings.

Although the proposed solution or correction you say sounds significantly easier than it is, I'm sure, is that last line instruction able to be added by the end user with any of the current available software amongst the community?

Onupdate is a papyrus event function, executing when a timed event created with the instructions, registerforupdate, or registerforsingleupdate, happens.
No. Indeed if the author didn't include the source code, editing it require more knowledge than the one required to make a script for starter. This is a really easy change to do for a modder with the source code though. The idea is to warn the author, to fix it in the next version

So, simply warn the authour like this: "Registerforupdate creates bloat, you should use registerforsingleupdate instead, adding a new registerforsingleupdate as the last line for the onupdate event".

extremely insightful, gratitude
This gives us the next step with a specific remedy upon discovery of a bloat culprit.

In line with updating a mod, and adding another line of update instruction, when a previous event had not completed; do you reccomend an alternate step/measure to take when updating a scripted mod?
My thought would be, logically speaking, that in order to prevent an overlap there must be a more effective method of removing an earlier mod version (and all inclusive scripts/instructions) so that the previous incomplete update event, could be removed entirely?

Not much to do about it. If the previous script onupdate events end by themselves (they should they are called functions that do something and then end, with so little change there shouldn't be further problems with functions not being able to end) the bloat will disappear on it's own really quick. If this didn't happen, you'll need to revert to a previous save.

@Amgepo
Can previous script onupdate event be expedited through ingame waiting/resting, or does real world time influence those updates? Or is that also mod specific? I ask because, in theory, an individual could load a bloated save and go to a safe location (as in a location where an idle character would not be attacked or under threat, and have the character just remain idle while user walks away from PC for several hours. So by allowing gametime to continue without interruption indefinitely, thus giving all scripts the necessary time to go through the onupdates until all events are triggered/ended to the point where only the active scripts remain. Again, in theory, this process would essentially debloat the file on the next save by giving the overlapped scripts the neccessary time to complete their instructed cycles/updates.

I assume this might be looking at from an overly fundamental level and odds are it just isn't that simple, but I figured I'd ask nonetheless

I think you're thinking of the reset period. The reset periods are 3, 10, and 30/31 in-game days. However, I don't know if this applies to your post or not.

@Death_Souls
Yes and no
I'm moreso referring to ampego's explanation of the onupdate events not completing before another set of instructions are overlapped and thus causing the bloated file.
In a way I am referring to the reset periods, provided that all and any onupdate events are based on the same time instruction as the reset periods. If the resets you listed are set intervals thag mod author have to abide by in papyrus throughout the script instructions , then they would coincide, therefore my suggested theory would be proved incorrect. Because the wait/rest 30 days ingame, followed by a clean save do not reduce the file bloats.
However, if the reset interval can differ than those you refer to, then it would stand to reason simply allowing gametime to pass for a long enough could eventually end/complete the onupdate scripts and reduce the overlap -> less bloat.
[I hope this is as coherent as it sounds in my head, haha]

...Back on thread OP slightly...

I mentioned earlier I am back on 1.5.26.05

Two mods needed updated in my list: Deadly Dragons & Occupy Skyrim (latest versions)
Abiding with clean save approach for both, I entered a new cell and saved then exited, and removed both.
Loaded clean save, played for a moment, saved and exited once more. Prior to installing latest versions of both mods, I checked my save file size and found a reduction approx 1/2MB
This, according to save history is the first reduction in size.
I'm not sure if this is simply the result of two cleanly removed mods and their respective scripts, or if this is relative to our issue if more time is allotted.
For the sake of our collective efforts, I am only reinstalling Deadly Dragons at the moment, and accumulate some game time followed by a revaluation of the save file sizes. And I will proceed to reverse the two by removing DD and adding Occupy Skyrim to compare the results.
Anyone else notice any correlation with either of these?

I had both installed during the original playthrough referenced in OP, which included many updates along the way. So if either had accumulating affects from their scripts, a substantial amount of time was given for both to have a greater impact.
In this case, I'm hoping to be able to dismiss either or both as possible culprits based on smaller sample periods.

The unbloating (once the corrections have been made on the script) will happen in real time. Anyway, it should be really fast. In theory a few minutes or even seconds should be enough. The same way scripts go slower as the bloat start, once the unbloated started the scripts should go faster, so the unbloating should go faster as time passes.

Of course that's if the save is stable enough to not have a CTD before the unbloating ends. Saving each few seconds could help otherwise.