TFS 1.2 Any Optimization suggestion

[Tbol]

[No, using new distro is not the option, sticking with legendary tfs 1.2, so any optimization comits would be appreciated, but legit ones that are tested]

[22/09/2025 18:06:07]
Thread: 1 Cpu usage: 94.0832% Idle: 5.35844% Other: 0.55837%
 Time (ms)     Calls     Rel usage %    Real usage % Description
      5586       295       19.79187%       18.62082% std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)
      4999     91145       17.71325%       16.66519% std::bind(&Game::checkCreatureWalk, &g_game, getID())
      3621     29551       12.83180%       12.07257% std::bind(&Game::updateCreatureWalk, &g_game, getID())
      2897      1720       10.26586%        9.65845% functor
      2319      1792        8.21824%        7.73198% std::bind(&Game::checkPlayersAttack, this)
      1956     16016        6.93175%        6.52161% &Game::playerSay
      1658       119        5.87537%        5.52773% std::bind(&Game::checkDecay, this)
      1139     45850        4.03695%        3.79809% std::bind(&Game::checkCreatureAttack, &g_game, getID())
       952      1809        3.37476%        3.17508% &Game::parsePlayerExtendedOpcode
       782     10892        2.77308%        2.60900% std::bind(&LuaEnvironment::executeTimerEvent, &g_luaEnvironment, lastTimerEventId)
       686      3358        2.43282%        2.28887% std::bind(&Spawn::scheduleSpawn, this, spawnId, sb, interval - 1400)
       653      1160        2.31692%        2.17983% std::bind(&Game::executeDeath, &g_game, getID())
       564      5437        1.99918%        1.88089% std::bind(&ProtocolGame::parseNewWalk, getThis(), playerWalkId, predictiveWalkId, playerId, playerPosition, flags, path)
       121      3400        0.43089%        0.40539% &Game::playerUseItem
        84      1647        0.30066%        0.28287% &Game::playerSetAttackedCreature
        47      2733        0.16898%        0.15898% std::bind(&Spawn::checkSpawn, this)
        44     17451        0.15692%        0.14764% std::bind(&ProtocolGame::sendNewPing, getThis(), pingId)
        37      2039        0.13223%        0.12440% &Game::playerTurn
        36     17451        0.12937%        0.12171% &Game::playerReceiveNewPing

 

[Gesior.pl]

     2897      1720       10.26586%        9.65845% functor

This 'functor' is XTEA encryption of outgoing network packets.
This simple fix will move that 9.65% CPU to network thread, so it won't waste 'dispatcher' thread CPU:

Move XTEA encryption from dispatcher to ASIO thread · gesior/forgottenserver-gesior@ba6df5e

A free and open-source MMORPG server emulator written in C++ - Move XTEA encryption from dispatcher to ASIO thread · gesior/forgottenserver-gesior@ba6df5e

github.com

IDK, if it's 1.2 compatible (may fail to compile with TFS 1.2 'boost::asio' that may require other parameter of 'socket'), but for sure there is similar code for TFS 1.2 that saves that 9% CPU.

      5586       295       19.79187%       18.62082% std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)

I would check lua.log. Maybe some event (onHealthChange etc.) wastes CPU in Lua or maybe it's just monsters logic - with a lot of active monsters - and you can't do anything about it.

      4999     91145       17.71325%       16.66519% std::bind(&Game::checkCreatureWalk, &g_game, getID())
      3621     29551       12.83180%       12.07257% std::bind(&Game::updateCreatureWalk, &g_game, getID())

In TFS 1.6+ there are few commits that finally made monsters walking use ~50% less CPU. It's probably ~500 lines of code and you will have to convert it to TFS 1.2 variable names/classes - a lot of work.

     2319      1792        8.21824%        7.73198% std::bind(&Game::checkPlayersAttack, this)

It looks like some 'fast attack' for players. There is already fast attack for players with 'classicAttack = true' feature in TFS 1.4. Maybe it would be more efficient than your checkPlayersAttack as it 'checks attack' only for players that are attacking and it works with millisecond precision, so it won't check all players every XX milliseconds to make weapon attacks fast.

 

[Tbol]

     2897      1720       10.26586%        9.65845% functor

This 'functor' is XTEA encryption of outgoing network packets.
This simple fix will move that 9.65% CPU to network thread, so it won't waste 'dispatcher' thread CPU:

Move XTEA encryption from dispatcher to ASIO thread · gesior/forgottenserver-gesior@ba6df5e

A free and open-source MMORPG server emulator written in C++ - Move XTEA encryption from dispatcher to ASIO thread · gesior/forgottenserver-gesior@ba6df5e

github.com

IDK, if it's 1.2 compatible (may fail to compile with TFS 1.2 'boost::asio' that may require other parameter of 'socket'), but for sure there is similar code for TFS 1.2 that saves that 9% CPU.

      5586       295       19.79187%       18.62082% std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)

I would check lua.log. Maybe some event (onHealthChange etc.) wastes CPU in Lua or maybe it's just monsters logic - with a lot of active monsters - and you can't do anything about it.

      4999     91145       17.71325%       16.66519% std::bind(&Game::checkCreatureWalk, &g_game, getID())
      3621     29551       12.83180%       12.07257% std::bind(&Game::updateCreatureWalk, &g_game, getID())

In TFS 1.6+ there are few commits that finally made monsters walking use ~50% less CPU. It's probably ~500 lines of code and you will have to convert it to TFS 1.2 variable names/classes - a lot of work.

     2319      1792        8.21824%        7.73198% std::bind(&Game::checkPlayersAttack, this)

It looks like some 'fast attack' for players. There is already fast attack for players with 'classicAttack = true' feature in TFS 1.4. Maybe it would be more efficient than your checkPlayersAttack as it 'checks attack' only for players that are attacking and it works with millisecond precision, so it won't check all players every XX milliseconds to make weapon attacks fast.

About the commit you posted it compiled just fine, but isnt it quite a dangerous change and risky to push or im tripping?

About lua.log this is the only three lua files that actually uses quite a bit, other ones are like 1 or 2%.
614 2029 14.52248% 2.04719% data/creaturescripts/scripts/extendedopcode.luanExtendedOpcode
532 12426 12.60084% 1.77630% (Unknown scriptfile)
284 12096 6.73169% 0.94895% data/creaturescripts/scripts/achievements.luanHealthChange

Also what about this one Remove redundant Game::cleanup on checkCreatureWalk. · otland/forgottenserver@6294694 (https://github.com/otland/forgottenserver/commit/62946948afc6fc751a3dcce6c70fff793477da70) isnt it like a small optimization aswell?

 

[Gesior.pl]

but isnt it quite a dangerous change and risky to push or im tripping?

All big OTSes use that fix for ~5 years. They use TFS 0.3, TFS 0.4, otserv (server older than TFS) and it works on each distro without any problems.

284 12096 6.73169% 0.94895% data/creaturescripts/scripts/achievements.luanHealthChange

Are there other onHealthChange Lua events with similar CPU usage (0.94%)?

It may be similar to 'quest log' problem in "canary" related to recalculating whole quest log every 'storage value change', which was fixed by queuing 'quest log' update for XX millisecond, so multiple changes by single Lua script won't call XX recalculations of whole 'quest log' (+ recalculate onLogin, so it works fine in case of player death). I would need to see that file content, to tell, if it's the same problem.

Also what about this one Remove redundant Game::cleanup on checkCreatureWalk. · otland/forgottenserver@6294694 (https://github.com/otland/forgottenserver/commit/62946948afc6fc751a3dcce6c70fff793477da70) isnt it like a small optimization aswell?

Looks fine.
It's not really 'redundant', but checkCreatureWalk is called Xk times per second with 100+ players online and other functions call cleanup(); at least 14 times per second, so skipping that cleanup(); saves some CPU and in worst case, it will make items - created/modified by walking?! something like "fire field" create by "Fire Elemental" corpse created by "Demon" walking into "Fire Elemental" - decay for extra 0.1 sec, as described in PR ( Remove redundant Game::cleanup() by Codinablack · Pull Request #4991 · otland/forgottenserver (https://github.com/otland/forgottenserver/pull/4991) ):

The reason we can do this without concern, is also the reason it's worth so much to gain... we already call Game::cleanup() every 100 ms in the Game::checkCreatures method.

Other optimization:

     1658       119        5.87537%        5.52773% std::bind(&Game::checkDecay, this)

It can probably be reduced significantly with my TFS 1.4 PR - some OTSes reported 99% less CPU usage by checkDecay, so your 5.52% CPU could go below 0.1%:

Optimized decay algorithm by gesior · Pull Request #2 · gesior/forgottenserver-gesior

Replaces "item decay" algorithm that decays all items every second - 99.9% of time it just decreases 'duration' attribute by 1000 ms - with algorithm that decays only items, which...

github.com

It was tested on multiple OTSes for over 6+ months, no crashes reported, no memory leaks reported, so it's probably stable.

 

[Tbol]

All big OTSes use that fix for ~5 years. They use TFS 0.3, TFS 0.4, otserv (server older than TFS) and it works on each distro without any problems.

Are there other onHealthChange Lua events with similar CPU usage (0.94%)?

It may be similar to 'quest log' problem in "canary" related to recalculating whole quest log every 'storage value change', which was fixed by queuing 'quest log' update for XX millisecond, so multiple changes by single Lua script won't call XX recalculations of whole 'quest log' (+ recalculate onLogin, so it works fine in case of player death). I would need to see that file content, to tell, if it's the same problem.


Looks fine.
It's not really 'redundant', but checkCreatureWalk is called Xk times per second with 100+ players online and other functions call cleanup(); at least 14 times per second, so skipping that cleanup(); saves some CPU and it worst case, it will make items - created/modified by walking?! something like "fire field" create by "Fire Elemental" corpse created by "Demon" walking into "Fire Elemental" - decay for extra 0.1 sec, as described in PR ( Remove redundant Game::cleanup() by Codinablack · Pull Request #4991 · otland/forgottenserver (https://github.com/otland/forgottenserver/pull/4991) ):

The reason we can do this without concern, is also the reason it's worth so much to gain... we already call Game::cleanup() every 100 ms in the Game::checkCreatures method.

Other optimization:

     1658       119        5.87537%        5.52773% std::bind(&Game::checkDecay, this)

It can probably be reduced significantly with my TFS 1.4 PR - some OTSes reported 99% less CPU usage by checkDecay, so your 5.52% CPU could go below 0.1%:

Optimized decay algorithm by gesior · Pull Request #2 · gesior/forgottenserver-gesior

Replaces "item decay" algorithm that decays all items every second - 99.9% of time it just decreases 'duration' attribute by 1000 ms - with algorithm that decays only items, which...

github.com

It was tested on multiple OTSes for over 6+ months, no crashes reported, no memory leaks reported, so it's probably stable.

Damn thats cool. Sadly about the decay the tfs 1.2 game.cpp is a bit different so some changes doesnt match. Like if (moveItem->getDecaying() != DECAYING_TRUE) { doesnt exist

Post automatically merged: Sep 22, 2025

about onhealth change

       242     10927        5.73298%        0.80707% data/creaturescripts/scripts/achievements.lua:onHealthChange
       232     10927        5.50649%        0.77518% data/creaturescripts/scripts/item stats.lua:onHealthChange
       115     10846      2.73167%        0.38455% data/creaturescripts/scripts/dmgRing.lua:onHealthChange
       85     10927        2.03348%        0.28627% data/creaturescripts/scripts/transform.lua:onHealthChange

 

[Tbol]

Difference with those two commits. Small improvement, but could be better

[23/09/2025 16:06:58]
Thread: 1 Cpu usage: 85.1682% Idle: 14.1816% Other: 0.650216%
 Time (ms)     Calls     Rel usage %    Real usage % Description
      5475    127118       21.43194%       18.25320% std::bind(&Game::checkCreatureWalk, &g_game, getID())
      5163       298       20.21028%       17.21273% std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)
      3653     43552       14.29728%       12.17674% std::bind(&Game::updateCreatureWalk, &g_game, getID())
      2160       120        8.45480%        7.20081% std::bind(&Game::checkDecay, this)
      1833     21379        7.17532%        6.11110% &Game::playerSay
      1231      2842        4.82033%        4.10539% &Game::parsePlayerExtendedOpcode
      1191     58945        4.66417%        3.97239% std::bind(&Game::checkCreatureAttack, &g_game, getID())
       946      1962        3.70456%        3.15511% std::bind(&Game::checkPlayersAttack, this)
       830      8319        3.25212%        2.76978% std::bind(&ProtocolGame::parseNewWalk, getThis(), playerWalkId, predictiveWalkId, playerId, playerPosition, flags, path)
       801      4866        3.13814%        2.67270% std::bind(&Spawn::scheduleSpawn, this, spawnId, sb, interval - 1400)
       761     11038        2.97916%        2.53730% std::bind(&LuaEnvironment::executeTimerEvent, &g_luaEnvironment, lastTimerEventId)
       697      1538        2.72832%        2.32366% std::bind(&Game::executeDeath, &g_game, getID())
       392      1993        1.53780%        1.30972% functor
       112      3221        0.44028%        0.37498% &Game::playerUseItem
        82      2257        0.32288%        0.27499% &Game::playerSetAttackedCreature
        56      3623        0.22251%        0.18951% std::bind(&Spawn::checkSpawn, this)
        48      4199        0.19086%        0.16255% &Game::playerTurn
        38     20176        0.15182%        0.12931% std::bind(&ProtocolGame::sendNewPing, getThis(), pingId)
        33     20176        0.13041%        0.11107% &Game::playerReceiveNewPing

 

[Ianoyo]

Your CPU has gone from 94% to 85%. So still good progress with just the changes Gesior has mentioned.

 

[El Bringy]

Difference with those two commits. Small improvement, but could be better

[23/09/2025 16:06:58]
Thread: 1 Cpu usage: 85.1682% Idle: 14.1816% Other: 0.650216%
 Time (ms)     Calls     Rel usage %    Real usage % Description
      5475    127118       21.43194%       18.25320% std::bind(&Game::checkCreatureWalk, &g_game, getID())
      5163       298       20.21028%       17.21273% std::bind(&Game::checkCreatures, this, (index + 1) % EVENT_CREATURECOUNT)
      3653     43552       14.29728%       12.17674% std::bind(&Game::updateCreatureWalk, &g_game, getID())
      2160       120        8.45480%        7.20081% std::bind(&Game::checkDecay, this)
      1833     21379        7.17532%        6.11110% &Game::playerSay
      1231      2842        4.82033%        4.10539% &Game::parsePlayerExtendedOpcode
      1191     58945        4.66417%        3.97239% std::bind(&Game::checkCreatureAttack, &g_game, getID())
       946      1962        3.70456%        3.15511% std::bind(&Game::checkPlayersAttack, this)
       830      8319        3.25212%        2.76978% std::bind(&ProtocolGame::parseNewWalk, getThis(), playerWalkId, predictiveWalkId, playerId, playerPosition, flags, path)
       801      4866        3.13814%        2.67270% std::bind(&Spawn::scheduleSpawn, this, spawnId, sb, interval - 1400)
       761     11038        2.97916%        2.53730% std::bind(&LuaEnvironment::executeTimerEvent, &g_luaEnvironment, lastTimerEventId)
       697      1538        2.72832%        2.32366% std::bind(&Game::executeDeath, &g_game, getID())
       392      1993        1.53780%        1.30972% functor
       112      3221        0.44028%        0.37498% &Game::playerUseItem
        82      2257        0.32288%        0.27499% &Game::playerSetAttackedCreature
        56      3623        0.22251%        0.18951% std::bind(&Spawn::checkSpawn, this)
        48      4199        0.19086%        0.16255% &Game::playerTurn
        38     20176        0.15182%        0.12931% std::bind(&ProtocolGame::sendNewPing, getThis(), pingId)
        33     20176        0.13041%        0.11107% &Game::playerReceiveNewPing

there is function cleanup() it should be cleaning memory, leave it only on checkDecay

 

[Tbol]

there is function cleanup() it should be cleaning memory, leave it only on checkDecay

So you mean deleting it from checkCreatures, void Game::shutdown() and void Spawn::checkSpawn() ?

 

[El Bringy]

So you mean deleting it from checkCreatures, void Game::shutdown() and void Spawn::checkSpawn() ?

keep it on shutdown for sure, you can remove it from checkSpawns and checkCreatures, checkDelay is completely enough

 

[Tbol]

keep it on shutdown for sure, you can remove it from checkSpawns and checkCreatures, checkDelay is completely enough

damn okay. Nice catch

 

[El Bringy]

damn okay. Nice catch

Thanks to @Codinablack

 

[Tbol]

gonna push it and check if there is any slight difference in performance

Post automatically merged: Sep 23, 2025

edit: it seems like deleting cleanup() from checkSpawns and checkCreatures fucks monster spawning, after this change monster dont spawn anymore

 

[El Bringy]

gonna push it and check if there is any slight difference in performance

Post automatically merged: Sep 23, 2025

edit: it seems like deleting cleanup() from checkSpawns and checkCreatures fucks monster spawning, after this change monster dont spawn anymore

Confusing because its not the case on my hobby project at all can you show me your Game::cleanup? I dont rememver tfs1.2 if it included data about spawns or not it shouldn't im sure it was only spawn we discussed that month ago on OTAcademy

 

[Tbol]

Confusing because its not the case on my hobby project at all can you show me your Game::cleanup? I dont rememver tfs1.2 if it included data about spawns or not it shouldn't im sure it was only spawn we discussed that month ago on OTAcademy

void Game::cleanup()
{
    //free memory
    for (auto creature : ToReleaseCreatures) {
        creature->decrementReferenceCounter();
    }
    ToReleaseCreatures.clear();

    for (auto item : ToReleaseItems) {
        item->decrementReferenceCounter();
    }
    ToReleaseItems.clear();

    for (Item* item : toDecayItems) {
        const uint32_t dur = item->getDuration();
        if (dur >= EVENT_DECAYINTERVAL * EVENT_DECAY_BUCKETS) {
            decayItems[lastBucket].push_back(item);
        } else {
            decayItems[(lastBucket + 1 + dur / 1000) % EVENT_DECAY_BUCKETS].push_back(item);
        }
    }
    toDecayItems.clear();
}

 

[El Bringy]

void Game::cleanup()
{
    //free memory
    for (auto creature : ToReleaseCreatures) {
        creature->decrementReferenceCounter();
    }
    ToReleaseCreatures.clear();

    for (auto item : ToReleaseItems) {
        item->decrementReferenceCounter();
    }
    ToReleaseItems.clear();

    for (Item* item : toDecayItems) {
        const uint32_t dur = item->getDuration();
        if (dur >= EVENT_DECAYINTERVAL * EVENT_DECAY_BUCKETS) {
            decayItems[lastBucket].push_back(item);
        } else {
            decayItems[(lastBucket + 1 + dur / 1000) % EVENT_DECAY_BUCKETS].push_back(item);
        }
    }
    toDecayItems.clear();
}

That won't work for you due to releaseCreatures

 

[Tbol]

Damn sadge, any more optimization commits that is worth doing and is compatible?

 

[Gesior.pl]

I would focus on:

       242     10927        5.73298%        0.80707% data/creaturescripts/scripts/achievements.lua:onHealthChange
       232     10927        5.50649%        0.77518% data/creaturescripts/scripts/item stats.lua:onHealthChange

Can you post these scripts or send me in private? Maybe there is some stupid logic or missing cache, that could make these scripts work much faster.

Can you post full lua.log, like you did with dispatcher.log? Maybe there is some well known Lua script that wastes much CPU.

---

Damn sadge, any more optimization commits that is worth doing and is compatible?

What CodinaBlack pointed is cleanup(); in void Game::checkCreatureWalk(uint32_t creatureId):

forgottenserver/src/game.cpp at 1.2 · otland/forgottenserver

A free and open-source MMORPG server emulator written in C++ - otland/forgottenserver

github.com

It's called 120k+ times per 30 seconds on your server and only change - after you remove it - will be that some 'fire/poison fields' of dead creatures will decay for 0.1 sec longer then they should.

I would not remove cleanup() from Game::checkCreatures(size_t index). This function is called 10 times per second, which gives fields - in this case ex. fire fields created by monster attacks like Dragon Lord - decay precision of at least 0.1 sec. If you remove it from there, only function that will call it, will be Game::checkDecay(), which is called 4 times per second, so delay precision will drop to 0.25 sec. Maybe players won't notice it, IDK.
// I did not analyse whole decay algorithm in TFS 1.2, maybe removing"cleanup()" from "Game::checkCreatures(size_t index)" won't affect it, but from my experience it will.

Spawn::checkSpawn()

You cannot remove cleanup(); from spawn.cpp. It's not same cleanup(); as in game.cpp. spawn.cpp cleanup is responsible for counting killed monsters, so spawn knows when to spawn new monster:

forgottenserver/src/spawn.cpp at 1.2 · otland/forgottenserver

A free and open-source MMORPG server emulator written in C++ - otland/forgottenserver

github.com

Anyway, all spawns related code use together less than 3% CPU:

801      4866        3.13814%        2.67270% std::bind(&Spawn::scheduleSpawn, this, spawnId, sb, interval - 1400)
 56      3623        0.22251%        0.18951% std::bind(&Spawn::checkSpawn, this)

Probably most of that CPU time it's spawning monsters, which creates new Monster object and checks area around monster position, if there are players - not much to optimize.

Difference with those two commits. Small improvement, but could be better

functor dropped from 9.65% to 1.30%:

2897      1720       10.26586%        9.65845% functor
 392      1993        1.53780%         1.30972% functor

Game::checkCreatureWalk increased in total from 16.66% to18.25%:

4999     91145       17.71325%       16.66519% std::bind(&Game::checkCreatureWalk, &g_game, getID())
5475    127118       21.43194%       18.25320% std::bind(&Game::checkCreatureWalk, &g_game, getID())

but if we divide number of calls by execution time, we can see that single checkCreatureWalk executes much faster:

• 18.23 events per millisecond before (91145/4999)
• 23.21 events per millisecond after (127118/5475) - 27% faster

Anyway, Game::checkCreatureWalk execution time can easily go +/- 50% without any change in code. Players can just go other map areas (other spawns/monsters) and it will change cost of 'walk' per event (ex. some tiles in area may have movement script like 'snow steps' executed every step). To measure real change, you would need to get all checkCreatureWalk from OTS stats from X hours, calculate average value and compare with OTS stats after changes.

Most noticeable lag indicator is Game::checkCreatures calls count. On not lagging OTS it's 299-301 per 30 seconds. On your OTS after changes it raised from 295 to 298. When it goes below 290, your server is probably running around 100% CPU or there is some super laggy C++/Lua script, that freezes OTS for XX milliseconds (check OTS stats slow/very_slow logs).

 

[Tbol]

I would focus on:

       242     10927        5.73298%        0.80707% data/creaturescripts/scripts/achievements.lua:onHealthChange
       232     10927        5.50649%        0.77518% data/creaturescripts/scripts/item stats.lua:onHealthChange

Can you post these scripts or send me in private? Maybe there is some stupid logic or missing cache, that could make these scripts work much faster.

Can you post full lua.log, like you did with dispatcher.log? Maybe there is some well known Lua script that wastes much CPU.

---

What CodinaBlack pointed is cleanup(); in void Game::checkCreatureWalk(uint32_t creatureId):

forgottenserver/src/game.cpp at 1.2 · otland/forgottenserver

A free and open-source MMORPG server emulator written in C++ - otland/forgottenserver

github.com

It's called 120k+ times per 30 seconds on your server and only change - after you remove it - will be that some 'fire/poison fields' of dead creatures will decay for 0.1 sec longer then they should.

I would not remove cleanup() from Game::checkCreatures(size_t index). This function is called 10 times per second, which gives fields - in this case ex. fire fields created by monster attacks like Dragon Lord - decay precision of at least 0.1 sec. If you remove it from there, only function that will call it, will be Game::checkDecay(), which is called 4 times per second, so delay precision will drop to 0.25 sec. Maybe players won't notice it, IDK.
// I did not analyse whole decay algorithm in TFS 1.2, maybe removing"cleanup()" from "Game::checkCreatures(size_t index)" won't affect it, but from my experience it will.

You cannot remove cleanup(); from spawn.cpp. It's not same cleanup(); as in game.cpp. spawn.cpp cleanup is responsible for counting killed monsters, so spawn knows when to spawn new monster:

forgottenserver/src/spawn.cpp at 1.2 · otland/forgottenserver

A free and open-source MMORPG server emulator written in C++ - otland/forgottenserver

github.com

Anyway, all spawns related code use together less than 3% CPU:

801      4866        3.13814%        2.67270% std::bind(&Spawn::scheduleSpawn, this, spawnId, sb, interval - 1400)
 56      3623        0.22251%        0.18951% std::bind(&Spawn::checkSpawn, this)

Probably most of that CPU time it's spawning monsters, which creates new Monster object and checks area around monster position, if there are players - not much to optimize.


functor dropped from 9.65% to 1.30%:

2897      1720       10.26586%        9.65845% functor
 392      1993        1.53780%         1.30972% functor

Game::checkCreatureWalk increased in total from 16.66% to18.25%:

4999     91145       17.71325%       16.66519% std::bind(&Game::checkCreatureWalk, &g_game, getID())
5475    127118       21.43194%       18.25320% std::bind(&Game::checkCreatureWalk, &g_game, getID())

but if we divide number of calls by execution time, we can see that single checkCreatureWalk executes much faster:

• 18.23 events per millisecond before (91145/4999)
• 23.21 events per millisecond after (127118/5475) - 27% faster

Anyway, Game::checkCreatureWalk execution time can easily go +/- 50% without any change in code. Players can just go other map areas (other spawns/monsters) and it will change cost of 'walk' per event (ex. some tiles in area may have movement script like 'snow steps' executed every step). To measure real change, you would need to get all checkCreatureWalk from OTS stats from X hours, calculate average value and compare with OTS stats after changes.

Most noticeable lag indicator is Game::checkCreatures calls count. On not lagging OTS it's 299-301 per 30 seconds. On your OTS after changes it raised from 295 to 298. When it goes below 290, your server is probably running around 100% CPU or there is some super laggy C++/Lua script, that freezes OTS for XX milliseconds (check OTS stats slow/very_slow logs).

Yea when it reaches 100 it becomes a problem becaue lag spikes appear. About checkCreatureWalk i have party module that displays party members maybe thats consuming a lot of resources now aswell particulary for checkCreatures.

lua.log

Spoiler: lua.log

[24/09/2025 06:55:59]
 Time (ms)     Calls     Rel usage %    Real usage % Description
       901      4322       17.28300%        3.00627% (Unknown scriptfile)
       645      2219       12.36401%        2.15064% data/creaturescripts/scripts/extendedopcode.lua:onExtendedOpcode
       318     14164        6.10180%        1.06137% data/creaturescripts/scripts/item stats.lua:onHealthChange
       283     14164        5.42914%        0.94437% data/creaturescripts/scripts/achievements.lua:onHealthChange
       200     15801        3.83983%        0.66791% data/events/scripts/creature.lua:Creature@onTargetCombat
       199     20657        3.82010%        0.66448% data/events/scripts/player.lua:Player@onGainSkillTries
       176       298        3.38550%        0.58889% data/spells/scripts/lvl150/sledgehammer.lua:onCastSpell
       163       200        3.13913%        0.54603% data/spells/scripts/lvl200/galactic pulse.lua:onCastSpell
       148     13975        2.84357%        0.49462% data/creaturescripts/scripts/dmgRing.lua:onHealthChange
       143      2219        2.75069%        0.47847% data/creaturescripts/scripts/tooltip.lua:onExtendedOpcode
       134       318        2.56793%        0.44667% data/spells/scripts/lvl50/ki repulsion.lua:onCastSpell
       116       582        2.23208%        0.38826% data/spells/scripts/lvl30/barrier.lua:onCastSpell
       105     14164        2.02912%        0.35295% data/creaturescripts/scripts/transform.lua:onHealthChange
       100       327        1.92991%        0.33570% data/creaturescripts/scripts/partyExtended.lua:onThink
        95      1265        1.83209%        0.31868% data/creaturescripts/scripts/dropcorpse.lua:onDeath
        95     44255        1.82383%        0.31724% data/events/scripts/creature.lua:Creature@onAreaCombat
        66       369        1.28384%        0.22332% data/spells/scripts/regeneration.lua:onCastSpell
        57       184        1.10195%        0.19168% data/spells/scripts/lvl200/selfdestruction.lua:onCastSpell
        53     14087        1.03374%        0.17981% data/creaturescripts/scripts/guild_manager.lua:onHealthChange
        53       237        1.02075%        0.17755% data/spells/scripts/lvl150/furie.lua:onCastSpell
        50       469        0.97214%        0.16910% data/spells/scripts/lvl10/renzoku energy dan.lua:onCastSpell
        47      1319        0.90827%        0.15799% data/events/scripts/player.lua:Player@onGainExperience
        44       250        0.84434%        0.14687% data/spells/scripts/lvl75/bigbangattack.lua:onCastSpell
        42        22        0.81810%        0.14230% data/creaturescripts/scripts/login.lua:onLogin
        34       370        0.66584%        0.11582% data/actions/scripts/heal/strong_potion.lua:onUse
        33      5551        0.64454%        0.11211% data/movements/scripts/snow.lua:onStepOut
        31      6189        0.60238%        0.10478% data/creaturescripts/scripts/ki barrier.lua:onHealthChange
        29      1257        0.57025%        0.09919% data/events/scripts/monster.lua:Monster@onSpawn
        29      1296        0.56803%        0.09881% data/creaturescripts/scripts/upgradeitem.lua:onKill
        29       148        0.56432%        0.09816% data/spells/scripts/monsters/czerwone pioruny.lua:onCastSpell
        27       111        0.53577%        0.09319% data/spells/scripts/monsters/rozowe fala.lua:onCastSpell
        27       172        0.52617%        0.09152% data/spells/scripts/lvl50/kienzan.lua:onCastSpell
        23        64        0.44514%        0.07743% data/spells/scripts/lvl150/kakarot.lua:onCastSpell
        23      4242        0.44157%        0.07681% data/events/scripts/player.lua:Player@onTurn
        22      1296        0.42635%        0.07416% data/creaturescripts/scripts/hercule.lua:onKill
        20       110        0.38353%        0.06671% data/spells/scripts/monsters/zolte ue.lua:onCastSpell
        19        99        0.36840%        0.06408% data/spells/scripts/lvl30/bakuhatsuha.lua:onCastSpell
        18       205        0.35512%        0.06177% data/spells/scripts/monsters/niebieskie pioruny ue.lua:onCastSpell
        17      1296        0.33749%        0.05870% data/creaturescripts/scripts/taskmaster.lua:onKill
        17        92        0.33527%        0.05832% data/spells/scripts/lvl50/swordfurie.lua:onCastSpell
        17      2219        0.33213%        0.05777% data/creaturescripts/scripts/autolootopcode.lua:onExtendedOpcode
        16      6189        0.32251%        0.05610% data/creaturescripts/scripts/immunity.lua:onHealthChange
        16      1296        0.31601%        0.05497% data/creaturescripts/scripts/autoloot.lua:onKill
        15        47        0.30334%        0.05276% data/spells/scripts/lvl150/kiexplosion.lua:onCastSpell
        14        87        0.28683%        0.04989% data/spells/scripts/lvl150/tsubikienzan.lua:onCastSpell
        14      1296        0.28486%        0.04955% data/creaturescripts/scripts/killing monsters.lua:onKill
        14       126        0.28320%        0.04926% data/spells/scripts/monsters/noga buu fala.lua:onCastSpell
        14        79        0.28095%        0.04887% data/spells/scripts/sregeneration.lua:onCastSpell
        14        54        0.27830%        0.04841% data/spells/scripts/lvl50/autodestruction.lua:onCastSpell
        14       338        0.27549%        0.04792% data/spells/scripts/monsters/red sword.lua:onCastSpell
        14       110        0.26898%        0.04679% data/spells/scripts/monsters/evil fala.lua:onCastSpell
        12      1267        0.24307%        0.04228% data/creaturescripts/scripts/prisonerevent.lua:onDeath
        12        27        0.23236%        0.04042% data/spells/scripts/lvl150/finalflash.lua:onCastSpell
        11      1296        0.22740%        0.03955% data/creaturescripts/scripts/grandpriest.lua:onKill
        11       378        0.21513%        0.03742% data/talkactions/scripts/transforms.lua:onSay
        11        49        0.21202%        0.03688% data/spells/scripts/lvl75/vitalpointattack.lua:onCastSpell
        10        28        0.20568%        0.03578% data/spells/scripts/lvl200/finishsign.lua:onCastSpell
         9      1296        0.18561%        0.03229% data/creaturescripts/scripts/killing mvp.lua:onKill
         9      1296        0.17261%        0.03002% data/creaturescripts/scripts/dailytasker.lua:onKill
         8        37        0.15805%        0.02749% data/spells/scripts/lvl50/jinruizetsumetsukogechi.lua:onCastSpell
         7        47        0.15312%        0.02663% data/spells/scripts/monsters/miecz.lua:onCastSpell
         7      1296        0.15119%        0.02630% data/creaturescripts/scripts/soul monster.lua:onKill
         7       399        0.14667%        0.02551% data/spells/scripts/power up.lua:onCastSpell
         7      1296        0.14431%        0.02510% data/creaturescripts/scripts/Karinquest.lua:onKill
         6        73        0.12683%        0.02206% data/actions/scripts/heal/senzu_bean.lua:onUse
         6        31        0.12297%        0.02139% data/spells/scripts/lvl50/blazingearth.lua:onCastSpell
         6        37        0.12218%        0.02125% data/spells/scripts/lvl50/crusherball.lua:onCastSpell
         6      1296        0.12033%        0.02093% data/creaturescripts/scripts/hakaispell.lua:onKill
         6      1296        0.11839%        0.02059% data/creaturescripts/scripts/RemoveStone.lua:onKill
         5        17        0.11486%        0.01998% data/spells/scripts/lvl75/erasercannon.lua:onCastSpell
         5       141        0.11390%        0.01981% data/spells/scripts/speed up.lua:onCastSpell
         5      2219        0.10372%        0.01804% data/creaturescripts/scripts/shop.lua:onExtendedOpcode
         5        52        0.10193%        0.01773% data/spells/scripts/power_down.lua:onCastSpell
         5        26        0.10058%        0.01750% data/spells/scripts/lvl75/maxenergyblast.lua:onCastSpell

 

[Codinablack]

I would not remove cleanup() from Game::checkCreatures(size_t index). This function is called 10 times per second, which gives fields - in this case ex. fire fields created by monster attacks like Dragon Lord - decay precision of at least 0.1 sec. If you remove it from there, only function that will call it, will be Game::checkDecay(), which is called 4 times per second, so delay precision will drop to 0.25 sec. Maybe players won't notice it, IDK.
// I did not analyse whole decay algorithm in TFS 1.2, maybe removing"cleanup()" from "Game::checkCreatures(size_t index)" won't affect it, but from my experience it will.

Yes because it's totally necessary for precision reasons to called 14 times a second