3. Extreme increase in CPU usage with the same script since the Withdraw update

Extreme increase in CPU usage with the same script since the Withdraw update

  • Culture

    As in title:

     

    http://i.imgur.com/KeedsNf.png

  • Dev Team

    Do you create a lot of flags within a tick? Room.createFlag method now creates a Flag object on every successful call, so it may consume some additional CPU.

  • Culture

    No, the only time I currently create flags is on room rcl increase or when a powerbank is spotted by observers. I dont create flags in any other way.

  • Dev Team

    I can't see any other possible reasons then. We didn't change any CPU-related mechanics in this update.

  • Culture

    It has dropped again suddenly. Might have been the V8 engine still optimizing serverside code after the update.

     

    http://i.imgur.com/W3RST3G.png


  • Does Spawn.createCreep has the same slowdown as Room.createFlag?

  • Dev Team

    Yes, if you make a lot of successful createCreep calls.

  • Culture

    The massive CPU increase is not worth the new feature. What are the chances we could convince you to revert it?


  • I understand the reasoning behind trying to add those (addressing the memory cleaning issue of new players). But it seems to just introduce a couple new classes of code:

    - Looping through creep, you have to check for .id always (it's a new mandatory check, and those types will cause bug for sure)

    - "Why is dead creep still alive?" -- Because players try to spawn before checking for dead-ness. We actually had like 2 people with this issue earlier today I think.

    - Iterating through Game.flags and Game.creeps while calling .createFlag or .createCreep seems like undefined behavior. I don't think it will cause issue most of the time with the for ... in loop, but it's conceptually murky to me.

    - All in all, I think the old idea of having all calculations of the same tick being done on the same game state makes it easier to reason. In this new case, .createCreep and .createFlag modifies the game state. For example, does two call to .createFlag of the same name both returns OK, or will one returns an error code ? 

  • Dev Team

    The massive CPU increase is not worth the new feature. What are the chances we could convince you to revert it?

    Could you please provide more info on your CPU increase? RegardingcreateFlag and createCreep isolated from other factors. Creating a new empty JS object should be quite negligible in comparison to constant CPU cost.

    • Looping through creep, you have to check for .id always (it’s a new mandatory check, and those types will cause bug for sure)

    You should have checked for !creep.spawning even before this patch. No need to check for id in most cases.

    • “Why is dead creep still alive?” – Because players try to spawn before checking for dead-ness. We actually had like 2 people with this issue earlier today I think.
    • Iterating through Game.flags and Game.creeps while calling .createFlag or .createCreep seems like undefined behavior. I don’t think it will cause issue most of the time with the for … in loop, but it’s conceptually murky to me.

    I can’t seem to get your point.

    For example, does two call to .createFlag of the same name both returns OK, or will one returns an error code ?

    No, the latter will return ERR_NAME_EXISTS. This is the same behavior as before the patch.

    All in all, I think the old idea of having all calculations of the same tick being done on the same game state makes it easier to reason.

    Yes, but inconsistences between Memory.creeps and Game.creepswhile spawning a new creep was the #1 problem for almost every newcomer, it had to be addressed somehow.

  • Culture

     

    I reported massive increases in CPU on PTR two days ago, but never got a response.

    http://screeps.com/forum/topic/916/Constant-CPU-usage-on-PTR

     

  • Dev Team

    I reported massive increases in CPU on PTR two days ago, but never got a response.
    http://screeps.com/forum/topic/916/Constant-CPU-usage-on-PTR

    It is not related to the game changes, it’s just an operational load due to our backend setup. The hardware on the PTR server is low priority.

    Do you experience increase on the live server?


  • - Spawning creep isn't an issue, at least not for me, since it's still a normal creep. I didn't check in detail, but at least some of the attribute of the dummy object in Game.creeps is different than an actual creep. I think it's missing body parts, causing some small issue with my planner code. Spawning creep doesn't cause an error, dummy creep does, so I have to check for ` id ` . Just to be clear, I thought it was a good change to address the issue for new comer too. But after the code went live, several players have problems with it in one way or another.

    - The inconsistencies between ` Memory.creeps ` and ` Game.creeps ` could be made clearer by making clear that calling ` .createCreep ` with memory is actually just setting value in ` Memory.creeps ` , and remove the memory clean up part in the tutorial code -- it's not necessary, and I think by the time they notice their large memory usage, they are used to the game model to know what to do.

    The change is not a big deal anyway. But I'm worried we will see more new players with different bugs from that. We can wait to see if it actually causes issue.


    • Iterating through Game.flags and Game.creeps while calling .createFlag or .createCreep seems like undefined behavior. I don’t think it will cause issue most of the time with the for … in loop, but it’s conceptually murky to me.

    > I can’t seem to get your point.

    Artem, I think, NhanHo's point is about added properties for Game.creeps object (iterating order and visiting is not guaranteed):

    Properties added to the object over which iteration is occurring may either be visited or omitted from iteration. In general it is best not to add, modify or remove properties from the object during iteration, other than the property currently being visited. There is no guarantee whether or not an added property will be visited, whether a modified property (other than the current one) will be visited before or after it is modified, or whether a deleted property will be visited before it is deleted. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in 

    So for now it seems like a dangerous under-hood feature with limited usage and undefined behavior, unlike previous API (which is questionable somewhere, but well described and predicable).

  • Dev Team

    I didn’t check in detail, but at least some of the attribute of the dummy object in Game.creeps is different than an actual creep. I think it’s missing body parts, causing some small issue with my planner code.

    The only difference should be id property. All other properties are set as in normal creep object.

    Artem, I think, NhanHo’s point is about added properties for Game.creeps object (iterating order and visiting is not guaranteed):

    Hm, I see, but what real-world scenarios would involve spawning a creep in the middle of iteration through Game.creeps? Seems like bad code organization anyway.

  • Dev Team

    remove the memory clean up part in the tutorial code – it’s not necessary, and I think by the time they notice their large memory usage, they are used to the game model to know what to do.

    It is neccessary. It is added to the Tutorial for a reason. Most new players are not able to identify the Memory dead creeps garbage problem and report their CPU increase as a bug.


    • Hm, I see, but what real-world scenarios would involve spawning a creep in the middle of iteration through Game.creeps? Seems like bad code organization anyway.

    Spawning copy of soon-to-be-dead or some other creeps?

    Not doing it, but someone might.