I have a 4 years old machine and i run all the mods that i want whitout any problem because the scripts CAN NOT SLOW DOWN THE GAME.
If you continue thinking that the scripts can give problems run my tests and convince yourself. See the source code if need.

As you can see, the capacity of the script engine is very impresive. The game can support hundreds and hundreds of scripts running at the same time.
And that only can give you some problems, like script lag, under specific circunstances like a constant script whitout external calls. 
That specific circunstances are very strange and normally not happend in the mods.

Can a script slow down the game?

Are there really "SCRIPT INTENSIVE HEAVY" mods?

The easy answer is "YES, of course, many people have problems caused by the script".

The REAL answer is NO, the game can run hundreds and hundreds of scripts at the same time without any problem.

For the first demostration you not need my test. You only need install Alernate Start and start a NEW GAME.
After create the character, the mod make an automatic savegame. Open it with ReSaver and look the Active Scripts section.

How many you have??? I can have more than 100 and that is NOT A PROBLEM for the game.
These scripts come from the initialization of all Quests with the Start Game enabled mark.
Not ALL Quest have a script for initialization, but, of course, many of them do.
The same happens when you load any saved game.
Hundreds of mods have a script for OnPlayerLoadGame and the game executes hundreds of scripts each time you load a saved game without any problem.
 

Download Test

I have done a mod with 4 different tests to demonstrate the capacity of the game and the results may surprise you.
All tests work with an event system to have several runs at the same time and can start 1, 25, 50, 100, 200, 400, 800, 1600 and 3600 events of each test.
Each event runs SIMULTANEOUSLY and you can save the game and open it with ReSaver to see that all events are in Active Scripts.

The test begins with the launch of a voice command called ST_VOICE and runs CONSTANTLY. You will hear a sound of water every time you use the Voice Command.
To stop the test, run the voice command again. You will receive a message indicating the duration of the test.

I added a latency checker in my mod to calculate the time needed to run 5 simple lines of code.
This special test is DIFFERENT from the latency test performed by the Elephant latency tester.
Elephant calculates the latency of the scripts with the OnUpdate event.
My test uses a call to the game engine that can calculate the REAL delay in the script engine.
In this way, Elephant can say that the game has a latency of 200 to 300 milliseconds, while my test can say that it has a REAL latency of 7-10 seconds.

TEST 1:
This test performs a CELL SCAN of all nearby npc and performs some checks on each npc.
During the execution of this test, your game should work normally and you should NOT notice that the test is running.
This is because the test has a large number of external calls that suspend execution many times at the cost of more execution time.
But this frequent suspension allows other scripts to be executed and for that the game can run 3200 events of this test without any problem.

TEST 2:
This test executes a MATHEMATICAL operation without stopping and only makes a call that can be suspended.
Each event of this test runs during ALL the asigned time of 1.2 or 1.6 milliseconds and can give you some problems.
While running this test, your game should work normally without losing any frames, BUT you may have a slow response from other scripts, for example any MCM.
This is because the test uses all the execution time in each event and can not be suspended because no external calls are made.
My events are running constantly and the game may take a few seconds to find a free execution slot and that may delay the execution of others scripts a lot.
This delay can go from 1 second to 30 seconds and YOU MUST HAVE IT IN MIND WHEN EXECUTING THIS TEST because that delay affects my own test.
The game may take a long time to display the message box to stop the test.
Then, when you press the voice command button to stop this test, WAIT for the message to appear.

TEST 3:
This test only have ONE line of code and is:
Game.GetPlayer().QueueNiNodeUpdate()
This line of code force the game to recompute all the mesh of the body of the player character and the game need a bit of time for made it.
This test is locked to ONLY 5 events for prevent CTD.
When i run this test with one event my frames down to half. If i launch 5 events my frames down from 60 to 5.

TEST 4:
This test is compatible with the other tests and I did it ONLY to demonstrate the capacity of the game and the priority system.
Enable a magic filter in each npc and show in the GAME CONSOLE how many magic effects are thrown in each npc in the cell.
If you enable the debug log in Skyrim.ini, you can see all the magic effects that are thrown on each npc.
You can activate test 4 and start any other test CONCURRENT, but to stop test 4 you MUST first stop the other type 1 or 2 tests and then stop test 4.
Of course, this filter adds load and may increase latency.

Final note:
When you want to STOP the test, use the voice command AND WAIT WAIT, WAIT, WAIT AND WAIT.
The mod works and the test stops and the message box appears, but it may NEED A LONG TIME.
ATTENTION: The game may need 1-3 minutes to stop 800 mathematical type 2 events.
ATTENTION: The game may need 1-6 minutes to stop 1600 mathematical type 2 events.
ATTENTION: The game may need 1-10 minutes to stop 3600 mathematical type 2 events.

Using this system, the ability of the game is really impressive because you can run hundreds and hundreds of scripts at the same time.
But this number can reach thousands when a mod has problems.
You can see a recent post from a user that reports 6600 active scripts. And I've seen more ... many more ...
Of course, those are games with problems because that is not normal. But it is really impressive.
 

I mentioned the execution queue before and it's another very interesting thing in the Skyrim script engine. It seems that this execution queue has priorities.
And this means, for example, that some scripts are executed before other scripts. This is a common technique in the programming of multi-threaded systems.
The priority determines when a script should be executed and this priority is used by the game to have a good response time.

When a script request a update in 5 seconds the game put that script in the exact position of the execution queue for be called in the exact moment.
In the same way, when a mod have some events registered the game call the scripts related to the events inmediately in the next frame.
That events are for example, magic effect, animation events, inventory management... all the events that must react to actions in the game.
When an npc launch a spell the asociated script can not wait and must be executed ASAP and the Script Engine put it in the execution queue inmediatelly.
In that way, some scripts are executed before others, because the execution queue is filled first whit the calls from new events.

But not everything is good because the ability to suspend the script is executed in the opposite way. Think a little and maybe you have the answer.
Yes, the script of a magic effect can start running immediately, but ... What happens when another function is called? Yes, the script is suspended and it loses its priority.
And the script should wait for the return of the called script. And for that reason, in some bad situations you can have thousands and thousands of active scripts.
Especially if the game calls the script again before the script finishes executing. In that situation, the count of active scripts can begin to grow to incredible points and cause problems to the game.

In some web pages, it is recommended to place the parameters in 800 milliseconds and make a small calculation, which is 80% of every second.
That means that the game can spend 800 milliseconds in creating an image, while the scripts are running, and you can have exactly 1.2 images per second.
You can go a little further and put the value in 2000 and you will have an image every 2 seconds or what is the same, 0.5 FPS.
You can edit the parameters in the [Papyrus] section of your Skyrim.ini and run my test to perform your own verification.

Using normal values of 1.2 or 1.6, the game only executes the scripts for 96 milliseconds or 10% of the time of each frame.
And what does it mean? Yes ... you have the answer ... the execution of scripts can not affect the frame rate or game performance.
 

When a game has problems, they are usually caused by the installation of the mods. Probably due to an outdated mod or collision or a bad dependent mod.

The only real problem comes from what the scripts do.
You can execute 100, 200, 300, 500, 1000 ... scripts that, apparently, are INTENSIVE WITH SCRIPT and the game does not have any problem.
But you can run ONE script and ONLY ONE and your game can start to slow down a lot.
Because the real problem is in what the scripts do.

THIS IS THE CAUSE OF THE STACK DUMP:
When a script register for a frecuent event and the script need a execution time superior to the frecuency of the event the game can enter in an infinite loop.
The game are processing the events and calling the function but, when the funtion can not be executed completely, the game can start the acumulation of scripts.
When the cumulated calls count go over the critical point the game make a STACK DUMP.
A lot of people think that get a STACK DUMP is bad but is FALSE.
The STACK DUMP is a protection of the game for try recover the normality. Simply the game stop all the script and start running it again.
A lot of times that is enough and the game start work normally again, because a lot of times, that tremendous spike of scripts are punctual.
But if the cumulated calls count start up again and go over the critical point the game make another STACK DUMP. And another and another and another...
And that mean a problem in one mod. Is not a problem in the game.
The game make the STACK DUMP for auto restart itself and try recover the normality.
But can not made it if a bad script from a bad mod is causing problems.

My test can create Stack Dump when start the test and probably generate a STACK DUMP every time you try stop a big test.
IS NORMAL... not worry... That not mean a problem in the game or a problem in the mod.
Because ONLY ONE STACK DUMP is not a problem.
When my test starts, 3200 events are sent and, sometimes, the script engine can not accept it and generates the STACK DUMP.
But after the STACK DUMP, the game regains normalcy and processes all events without any problem.
You can activate the registry in your Skyrim.ini and see how the STACK DUMP is generated and how my test runs without any problem.

The STACK DUMP can NOT make PERMANENT DAMAGE and can NOT break any script of any mod.

The game suspends all the scripts before doing the STACK DUMP and restarts them EXACTLY in the same point.
A script can NEVER lose a line of code for a STACK DUMP because the STACK DUMP is a game protection to RESOLVE a problem and can NOT cause another problem.
Normally, my mod generates a STACK DUMP when the event is sent to stop the test. But ALL events receive the stop command AND there is NEVER a pending script running.

If you get a large amount of STACK DUMP or get frequent STACK DUMP are caused by a problem in a mod.
Of course, ONE STACK DUMP and ONLY ONE are not a problem, can be caused by a punctual overcharge in the game.

This is because the log of Skyrim is a BUFFERED file. When the game wants write some to the log really are writing it in memory.
The work of write the file to the hard disk is made by the operating system and is NOT made by the game.
Normally, a BUFFERED file is managed in chunks of 4 kb and write 4kb of data in the disk is a stupid operation for the machine.
This buffer of 4 kb can be dinamically increased, but only in the operating system side, to 64 kb if necesary.
In this way, when the game need put a lot of lines in the log the operating system dinamically increase the internal buffer size for reduce the hard disk operation.
And for that reason, the SPAM IN THE LOG can not give any problem to the game.

First, you MUST know the basics. The game does NOT activate ALL the scripts of all mods by default.
The game activates ONLY the script related to the ACTIVE quests of the mod, and of course, only SOME mods will activate ALL of its quest at the beginning. See the screenshots:

In the first screenshot, you can see the slaverun script folder and it has 4097 scripts.
In the following screenshot you can see one of my saved games and if I filter it by SLV I can see how many scripts I have of slaverun.
How many scripts i have??? Only 670 and i not have the 4097 scripts of slaverun loaded.
That is because ONLY some quest of slaverun are active and the game load ONLY the scripts related to the active quest.
When a new quest is started automatically load all the scripts of the quest. 
Of course, when a quest is completed, the game discards all scripts and related data.
But load the scripts not mean EXECUTE them. The game load it ONLY for have it in READY FOR EXECUTE state and execute it when need.
In a mod with dialog near half of the scripts are related to the dialog and are executed ONLY when the dialog line is selectect.

Then, if a mod have thousand and thousand of scripts that NOT MEAN IS SCRIPT HEAVY INTENSIVE.
The only problem caused by the number of scripts is the string table bug because each script need a space in the string table.
If you install a lot of mod's with a lot of script, quest, alias, animations... your game can have the string table bug.
But this problem has been solved by Crash Fixes 12 more than 3 years ago and i think nobody have this problem today.