ServerForge - Server Optimization (w/ Logs, Profiler, Anti-Crash, Real-Time Stats and Admin Panel) W

[rich yoke]

does it work with coroutines

[slow ridge]

my script does not specifically monitor or profile Lua coroutines. The lag detector measures main-thread tick intervals (and the profiler wraps hooks to measure hook CPU), so it only records spikes that manifest as delays on the main server tick. If a coroutine blocks or otherwise delays the main thread, that delay will show up as a spike; if a coroutine yields/resumes without blocking the main tick, its internal work will not be detected. To track coroutine activity directly I'd need to instrument coroutine.resume/create (or add profiling around where coroutines are run)

(lag detector talking)

but if you talk about the build of the script no i dont use coroutines but i will for a next update it a free old project that i updated and released

[formal lodge]

no, it slows down the game thread to check

[past moss]

The description keep mentioning "direct engine integration" and yet i can't see any mention of optional binary module for the addon, is this just a whole chatgpt addon by the look of the description

[slow ridge]

i think he mean if the script build use coroutines or classic loop

[formal lodge]

if it checks for coroutines that might hang the process, yeah- coroutines in gmod are processed in the game thread anyway

[slow ridge]

Direct engine integration For the metaphorical form

[slow ridge]

Checking coroutines will kill the CPU

[slow ridge]

This is a way of explaining that it uses processes already integrated into the game engine and cleans up things that the engine generates, for example, the engine's garbage collector.

[formal lodge]

we can count the iterations if it's a runaway coroutine (while true) via debug.sethook

[slow ridge]

Do you think building a Glua script using coroutine will be fastest than using loop ?

[slow ridge]

Yeah but it will be for a Profiller script like FProfiller

The addon in question doesn't have a very powerful profiler to avoid overloading it; it uses a standard profiler because it consumes a lot of resources

[formal lodge]

you mean running your logic in a coroutine vs Think hook? Not really any difference I believe

[slow ridge]

Yeah

[formal lodge]

you get a little more control on when it executes, yielding or waiting, but you can do that in Think too with curtime variable, making a queue or however you wish

[slow ridge]

yeah that what i do i think it rare to see someone using coroutines in gLua

[formal lodge]

If they were each on their own thread then you'd see more usage (with more caveats, probably, like them being unable to get data from each other), but in glua they're all processed by the main thread

[slow ridge]

So that would bring the permutation system back to life.

[slow ridge]

And for that message it's pure Lua there’s no optional binary/native module included. The ‘direct engine integration’ line in the description is marketing wording : everything runs via standard Garry's Mod Lua hooks and scripts.

Like a Ready to use package

And that addon is a private thing that i made by the begining of the year for private use and i just updated it for public release

And for the description i used ChatGPT to translate since im Arabic

So there may be some phrases that were incorrectly transcribed from Arabic to English.

[rich yoke]

I've just had experience with profiling tools blaming my coroutined code for dozens of seconds of perf drain

they just count when the functions start/end, so they end up adding all that time the functions are yielded and not actually running

[slow ridge]

Yes, because most profilers don't analyze the inside of coroutines; they only retrieve the entry and exit points.

[slow ridge]

Yeah, it's a known pain point with those profilers. They usually just track the clock time between a function call and its return.
Because a coroutine's yield doesn't technically end the function, the profiler keeps the timer running the whole time it's waiting for the next tick. It totally skews the results, making background logic look like it's freezing the game when it's actually doing nothing. Classic GMod profiling issue.

It's technically possible, but it's a huge pain. You'd have to manually inject debug.sethook into every single coroutine thread, since they don't inherit hooks from the main state.
The real killer is the performance hit. Attaching debug hooks to every yield and resume adds massive overhead. It would slow down the game so much that your timing data would be totally trashed you'd be measuring the profiler's lag more than your actual code. That’s why most people just stick to manual SysTime() checks; it's cleaner and doesn't tank the frame rate

[rich yoke]

shame, would be a killer feature

[slow ridge]

I can do it

[rich yoke]

even just a toggle would be amazing