How is everyone dealing with the CPU limits?
-
I regularly exceed my CPU limit these days despite refactoring and optimizing a number of times. I've been doing benchmarking trying to fully understand the CPU limits and what counts the most against it.
Some things I've found are the "canCreateCreep" and "isNearTo" checks seems more CPU intensive than just letting the "createCreep" or "move" functions fail. It also appears that "find" with a filter is greatly superior to "lookForAt".
What are some things others have found for cutting down on CPU cost?
-
A quick addition, I'm at a loss for figuring out why there is so much variation between rounds. Running the same "find" command over 10 rounds can be as low as 0.5 CPU or as high as 15 CPU, when one would assume the time should have a much smaller spread. This is true for almost all functions I've tested using the built in CPU checks.
-
Given most of my slow downs are related to the API, I'm slowly migrating to my own implementation. It would also give me opportunities to take advantage to reduce the number of calculations for doing the same thing, which can be done by caching or only spend CPU cycles doing the specific stuff I want.
That said, I do a lot of benchmarks using timers and the result are this: Starting and requiring (I do all requires at once for now) are taking a lot of time, where start takes about 5-10 ms and require around 6-20 ms.
Giving creepers their orders do consume a lot of time, where currently about 100 ms is spend, mostly on creeps travelling more than 10 tiles away (not sure if its the lookup or path finding that consumes most of the time), they spend about at least half the time spend while giving creeps orders.
So yeah, I guess we do need a better pathfinder
-
Wow, it looks like the creators are already planning to replace the pathfinder with a native implementation... I still want to burn my hypothesis that the pathfinder just isn't optimal for the job... http://support.screeps.com/hc/communities/public/questions/201265461-Exceeding-CPU-limit-without-creeps
-
Will love to see the pathfinding script enhanced. Making my own pathfinding algorithm isn't high on my list at the moment. The current pathfinding really does eat at the CPU, especially when you're coordinating 100+ creeps.
-
I found the setup of the code rather expensive. Having a CPU check as first line(!) in my main game me 10~50 CPU consumed already! At this point the consumption should be always 0 imo! After having all my prototypes required I was down another 5-15 CPU. This also could be a point of optimization - having the prototypes (and probably also the other code) not being recompiled every gametick (unless we introduce any changes, which in turn should be easy to detect).
-
I don't have CPU problems anymore since I started caching all the paths, I now have a memory problem.
-
I'm definitely finding improvements caching more information. Especially when it comes to some of the require statements. However, I would personally like to avoid having to write a pathfinding algorithm, and I look forward to seeing the internal improvements to pathfinding.
With that, there is still wild variations in what the cpu is reporting. A spread of a +/- 10% would make sense, but there are spikes that make that spread hard to deal with when trying to find optimizations.
-
I've also stopped using the require statements - all my code is still maintained in different files, but it's concatenated to one single js file on build, Screeps is set to sync from the folder that has only the main.js file.
-
Concatenating makes a lot of sense to do. Let you keep things organized, but keeps things quick on the game's side.
-
We have just made some changes in the runtime engine. See more in this article.
