TFS 1.X+ High CPU usage in checkCreatureWalk (TFS 1.5 Nekiro 8.60)

[Dolot2003]

Hello everyone,

I'm currently running a server using the TFS 1.5 8.60 (Nekiro Downgrade) and I'm facing significant CPU performance issues when the player count increases. Looking at the internal profiler, it seems that the A* pathfinding algorithm and creature walking logic are consuming the vast majority of my CPU resources.

Here is my current server profile output:

[01/07/2026 13:31:05]
Thread: 1 Cpu usage: 69.4008% Idle: 29.6636% Other: 0.935578% Players online: 249
Time (ms) Calls Rel usage % Real usage % Description
11081 750833 53.22691% 36.93993% std::bind(&Game::checkCreatureWalk, &g_game, getID())
2461 33043 11.82279% 8.20511% std::bind(&Game::updateCreatureWalk, &g_game, getID())
1766 300 8.48225% 5.88675% std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)


As you can see, checkCreatureWalk is responsible for over 50% of the relative CPU usage. With around 250 players online, this is causing noticeable lag spikes.

I know there are already plenty of threads on OTLand discussing pathfinding and CPU optimization, and I've spent quite a bit of time reading through them. Unfortunately, it's very difficult to find solutions that are actually relevant to TFS 1.5 8.60 (Nekiro Downgrade). Many of the suggested fixes are outdated, incomplete, or no longer apply to this branch, while others don't seem to have any measurable effect or introduce new issues.

Has anyone encountered this issue on the Nekiro downgrade? Are there any known optimizations, patches, or configuration tweaks to reduce the CPU load caused by pathfinding and creature walking without breaking the core game mechanics?

If you've managed to improve the performance of checkCreatureWalk or the A* pathfinding system on this version, I'd really appreciate it if you could share your approach or point me to a patch that has been tested and proven to work.

Any help or suggestions on how to profile or optimize this further would be greatly appreciated.

Thanks in advance!

 

[Sorky]

I would try to use what @Codinablack did for his Blacktek:

Pathfinding Overhaul - Refactored into a binary heap pattern for opti… · Black-Tek/BlackTek-Server@61b26cc

…mal performance

github.com

 

[Dolot2003]

I tested these changes on my server and saw a significant improvement.
std::bind(&Game::updateCreatureWalk, &g_game, getID()) and
std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)
now use considerably less CPU than before. However, std::bind(&Game::checkCreatureWalk, &g_game, getID()) is still the biggest bottleneck and continues to consume around 36% CPU under heavy load. It would be great if this part could be optimized further as well.

 

[Mateus Robeerto]

Small correction: I wouldn't blame only A* here.

The profiler shows a movement pipeline bottleneck: checkCreatureWalk, updateCreatureWalk, checkCreatures, walk scheduling, follow/chase logic, spectator lookup, and repeated movement checks.

Replacing the A* implementation may help, but if checkCreatureWalk is being called hundreds of thousands of times, the main issue is also how often movement is scheduled and recalculated.

On Nekiro 1.5 8.60, this is expected under high load unless the movement logic, spectator filtering, and path recalculation rules are optimized together.

 

[Codinablack]

I would first recommend getting rid of the std::bind usage, in favor of passing a lambda like all the modern servers are doing.. that will be a nice help... but really, if you know anything at all about coding, then you are best off using your profiler to break down where the calls are coming from, and which parts of the calls are hot, so you can find the problem... just knowing that "X" process is the one consuming highest CPU usage doesn't give you much information to act on... you need to know which parts of that method are taking up the most cycles.. for that, you need a proper profiler, not that crap ass kondra nonsense... which, btw, is likely part of your problem in the first place, as using that system is just adding more overhead...

So to recap, drop std::bind usage, use a real profiler, and get rid of the kondra overhead nonsense on your task system... These are my personal suggestions... but other than that, you can find some more optimizations in blacktek, and I think the addwalk thing, I think I remember being able to make it more effecient by adding a "true" boolean as the second param to the call made to the monsters onThink, and that made a huge difference... but I can't recall if it made it called less or just made the monster more responsive... I forget... but yeah... use a real profiler to find the problems... because almost all methods have calls to other methods/functions, it's almost never as simple as "oh it's this one call that is high cpu usage"... it's, yeah ok, this call, which has like 3-4 places which are "hot".. as in, they are consuming high cpu cycles... and you will never be able to see this information with that ridiculous and worthless, kondra "stats system"...