Extreme increase in CPU usage with the same script since the Withdraw update
-
-
Do you create a lot of flags within a tick?
Room.createFlag
method now creates aFlag
object on every successful call, so it may consume some additional CPU.
-
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.
-
I can't see any other possible reasons then. We didn't change any CPU-related mechanics in this update.
-
It has dropped again suddenly. Might have been the V8 engine still optimizing serverside code after the update.
-
Does Spawn.createCreep has the same slowdown as
Room.createFlag
?
-
Yes, if you make a lot of successful
createCreep
calls.
-
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 ?
-
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? Regarding
createFlag
andcreateCreep
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 forid
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
andGame.creeps
while spawning a new creep was the #1 problem for almost every newcomer, it had to be addressed somehow.
-
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
-
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-PTRIt 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).
-
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.
-
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.
- Hm, I see, but what real-world scenarios would involve spawning a creep in the middle of iteration through