...one more thing I'll add is that I tested within a private server environment I'm hosting, so I'm not confined to any CPU limit.  I don't know what would happen if you ran my test in the official world instance.  And the fact that my CPU utilization maxed out may also be partly due to the fact that the server I'm renting from GoDaddy is not the best (only two cores provisioned to my VM).

Hey tedivm,

I did some testing and I can confirm that the script size is not something anyone should actually worry about.  First, I'll say that after looking at your code I knew if you ran that and saw a difference in what is stored in Game.cpu then yes, you're right in that it counts against your CPU (I didn't run the code myself but I trust in what you reported).

That said, I also know that "compiling" the code does not take a lot of real CPU time and shouldn't be a concern when playing this game.  To prove that, here is what I did:

1. Created a script named "bigscript" which has 30K+ lines of code:

<code>

var bigscript = function () {

var _run = function () {
for (var roomName in Game.rooms) {
var room = Game.rooms[roomName];
var spawns = room.find(FIND_MY_SPAWNS);
var creeps = room.find(FIND_MY_CREEPS);

var upgraderCount = creeps.filter(function (c) {
return c.memory.role == 'upgrader';
}).length;

var harvesterCount = creeps.filter(function (c) {
return c.memory.role == 'harvester';
}).length;

var builderCount = creeps.filter(function (c) {
return c.memory.role == 'builder';
}).length;

var energizerCount = creeps.filter(function (c) {
return c.memory.role == 'energizer';
}).length;
}
};

var _run = function () {
for (var roomName in Game.rooms) {
var room = Game.rooms[roomName];
var spawns = room.find(FIND_MY_SPAWNS);
var creeps = room.find(FIND_MY_CREEPS);

var upgraderCount = creeps.filter(function (c) {
return c.memory.role == 'upgrader';
}).length;

var harvesterCount = creeps.filter(function (c) {
return c.memory.role == 'harvester';
}).length;

var builderCount = creeps.filter(function (c) {
return c.memory.role == 'builder';
}).length;

var energizerCount = creeps.filter(function (c) {
return c.memory.role == 'energizer';
}).length;
}
};

// KEEP REPEATING THE DEFINITION OF _run() UNTIL YOU HAVE 30K+ LINES OF CODE

return {
run: _run
};

};

module.exports = bigscript();

</code>

2. Then in the main script:

<code>

var bigscript = require('bigscript');

module.exports.loop = function () { };

</code>

If you do this, you'll notice that for the first two ticks you'll see CPU utilization (the graphic in the upper-right part of the screen) completely max out.  That proves you are right about it affecting CPU time.  However, after it uploads and a couple ticks pass, CPU utilization returns to normal and is then only affected by what code is actually executed per tick-- proving that the modules are cached (as you mentioned), which is how 'require' natively works (ie, even outside of this game).  The CPU spike only occurs when submitting new changes.  

A momentary spike is not something to warrant a change to your workflow, toolchain, etc.  Also remember that the spike you observe by following the test I produced is with a script that has 30K+ lines of code-- something that I can't imagine would be achieved through the normal use of this application/game.

Cheers,

Bones

tedivm,

I found this article, which explained enough for me to have a good idea as to how it works: http://support.screeps.com/hc/en-us/articles/204332302-How-does-CPU-limit-work

What they really care about is how long it takes for all your scrips to execute per "tick," or player turn.  They must capture the current time before starting your scripts (calling module.exports.loop), then capture the time after it completes, calculate the delta, etc.  Your CPU limit explicitly defines the number of milliseconds they will allow your scripts to run.  

The good news is that if you underutilize the time provisioned to you, then the excess gets carried over into the next tick (up to 10 seconds worth), which will allow for the occasional spikes.  Though it's also worth noting that there is a 500 ms maximum per tick.

I don't think load or "compile" time is factored into play here, but even if it was a few spikes here and there aren't an issue.

As a noob I'm just guessing here, but I don't think the CPU cost is based on the number of lines or characters of code.  I think instead it is based on the number of function calls you make and for which functions you call (functions have different costs roughly based on how much real CPU work they do).

I think this is true because I've seen my CPU cost fluctuate based on the frequency at which I run a certain module.  I have corrected the issue by adjusting the frequency using a little modulus math:

if (Game.time % 25 != 0) return;

...not everything needs to run at every tick.

Hope that helps.