Changelog 2017-07-05

  • Dev Team

  • Culture

    Amazing change! Thank you for upgrading the runtime versions.

  • Maybe not related, but I'll mention it just in case. In the half hour that this has been active, I've seen 7 occurrences of:

    "Script execution timed out: CPU limit reached"


    Edit: after another hour, I'm up to 29 timeouts.

  • As kshepard mentioned, my script is seeing a large number of timeouts since this update. The performance drop is fairly dramatic unfortunately.

  • same here.. In my script those ticks starting with a massive memory loading time. I have detected: 280-380CPU for ~900kb.. 

  • Culture

    On the opposite side, my code actually seems to be doing better, CPU usage staying at the usual average of 100, but bucket is staying a bit higher and more of my kernel processes are running every tick. (Sometimes even all of them)

    Looking at graphs, new globals seem to not be hitting me as hard as they used to either

  • I experience much more timeouts than before the update (4 timeouts yesterday and ~50 since the update).

    Also, there are no more invaders since the update


  • So far the CPU use seems more consistent and the compilation penalty is not as high.

  • Zoom out the the 7 day display on ... can you guess when the update was done?!?  

    From the looks of it this is hitting most players' CPU pretty hard.  I'm regularly seeing 100 - 230 CPU used already on the very first line of my loop.  I only get 80... so at this point the game is completely broken.   On normal turns I'm running 45 to 70 depending on if I run my check deals code... but 1 / 5 or more of my turns start out as described.  It does not specifically coincide with the code reloading as my code detects these runs and displays this run-time usage statistic as well which also seems to be much higher than normal.  

    I'm also seeing creeps regularly using 4x to 10x the CPU they were before... not every turn, but more often than not on the same turns as the issue above.

  • Culture

    Creep CPU usage is normal for me, most of my creeps are running at their usual ~0.25/t usage

  • Culture

    My code is very very happy with this upgrade- things are working so much faster.

    One thing I am noticing though is that JSON is actually performing worse with these upgrades than it did before. I'm seeing this in two places- my memory parse time went from 18cpu a tick to 26cpu a tick, and the json stringify call for saving statistics into a segment is also significantly higher.

    Overall this is still a huge win for me, as the improvements in speed in other places more than makes up for the json changes.

  • Dev Team

    Runtime workers now will be reset every 10 mins, let's see if it makes any difference.

  • It made a little bit of difference for me. I'm receiving fewer timeouts, but am still seeing on average one timeout every 10 minutes.

  • Culture

    The workers reseting more often has made my code perform worse, 
    CPU is more eratic (
    Memory parse is on average more expensive too (
    Ignore the long gap in the graphs, my stats agent died during that period.

  • Culture

    Did the recent change trigger a reset storm? I'm seeing a performance drop but it could just be the reset storm.

  • It seemed a little better after the reset frequency change, but now I'm back to getting a timeout every minute or two for the past hour or so.

  • Dev Team

    Node.js has been rolled back to 6.11.0 LTS. It doesn't seem to be stable enough. We'll get back to it when some fixes appear, and/or 8.x branch becomes the next LTS.

  • Sounds like a good decision, thanks! It was worth a try.

  • Culture

    Ever since you reverted the code back my system has been performing like absolute crap. Before the update to node8 I was running about 220 programs a tick, after the upgrade it went up to 260 programs a tick, and now that you've reverted it my system is running at 160 programs a tick.

  • My average CPU per tick dropped by about ~10 while we were running Node 8. I really hope we don't have to wait too long for this upgrade.