Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

GMLive.gml

Livecoding for GameMaker: Studio / GameMaker Studio 2 · By YellowAfterlife

[Fixed in 1.0.47+] gmlive and fps

A topic by DrunkenStork created Feb 06, 2021 Views: 396 Replies: 7
Viewing posts 1 to 3

Is there a reason gm_live would be draining so much of my fps? I tried running it with 1 live_call in an object of my game, and I was at 20fps. I thought maybe it could have been something to do with my project, so I thought I would test it in a fresh project with nothing in it other than gm_live. The debugger without a live_call active shows 9000+ frames, no surprise there. But using just the 1 default live_call in the draw event of obj_gmlive dropped it down to 800-900 frames, which is fine in an empty project, but I haven't been able to use gm_live in my current project. Is there something I'm missing or should be looking for? Game Maker runtime v2.3.1.409. Thank you!

Developer

There is a section about this in documentation - essentially GMLive has an implementation of a bytecode interpreter so it is always going to be slower than “native” code.

The only way to avoid such caveat would have been to compile and inject new bytecode into the game’s process, but this would increase the development and maintenance costs by more than order of magnitude, along with making the extension impossible to run on platforms where memory injection is harder/forbidden (mobile, console, web).

In particular, self-variable access is one of the fastest things in pure GML (as access is cached to the best ability), but has to use variable_instance_ functions in GMLive, which aren’t that fast. Assigning repeatedly reused instance variables into local variables helps with that.

There are also some issues with 2.3.x changes - e.g. I had recently noticed that try-catch is slower than you’d expect. You can experiment with setting gml_thread_allow_exceptions to true and adding a try-catch around the if (live_call line if you foresee code causing an error.

Thank you for the insight and fast reply!

Gmlive used to be quite fast until the update to 2.3 . Now it is very slow, even a few calls  if (live_call()) return live_result;   brings a massive drop in fps.  I don't know why it happens, I don't even use structs nor new gml features :( 

Developer

You can try GMLiveForGMS2.3-experimental.yymps - it ditches structs in favor of 2.2.5 style arrays, though it’s ultimately hard to profile performance now due to garbage collector.

Developer (1 edit)

I have news: apparently debug_get_callstack (which GMLive uses to figure out what script is being executed) gets progressively slower the more code you have in scripts that were called - even if that code is commented out. With GMLive now being a massive script, that is an issue.

I filed a bug report (#180892) and will look into mitigating this (likely by splitting the script into smaller scripts).

A workaround is to use live_name, which will then omit calling debug_get_callstack.

Thank you for a quick reaction. It would be fantastic if YoYo fixes the bug and  GMLive works as fast as it used to before the update to 2.3. 

Developer(+1)

I have now released a new update that splits the GMLive’s big script into a handful of smaller scripts, which is enough to address general use cases (and if your profiler shows that debug_get_callstack is taking up a lot of time, you can still use live_name).