Ah well. Read that lua did have garbage collection(
Programming in Lua : 11.6), and assumed it'd apply to the lua things I create. Ultimately, in the tests above I just displayed 9 lines of text.
And well, sure the code snippet won't work on it's own; myscreen is defined, but newscreen is a modified gui.Framedscreen obtained by a screen constructor function.
---
What/why am I benchmarking?
Well, you said that the main concerns would be memory leaking and flickering in a different way, provided it doesn't crash. I'm testing how much memory does leak, and whether setting viewscreen to nil before dismissing the gui.Framedscreen results in a bigger memory leak.
Hm, to further test that dismiss doesn't leak memory with something simpler...Using a simpler gui/hello-world with 100 frames to dismiss results in 381,4 MB → 385,7 MB and stays there, or 0,04 MB per screen. (Fair enough, the modified screen is more than a magnitude larger all right.)
Since that was kind of small difference, ran it 101 times again without closing down DF this time and it went from 385,7 to 387,2. 4,3 MB vs 1,5. A third 101 goes to 378,8.
Decreasing each time...going back to the more complex screen used in initial benchmarking last page, two x 101 dismiss-only runs bring it from 380,7 MB → 1,3 GB→2,6 GB→didn't run a third time (Also wtf.). Three runs that use the code snippet setting to nil before dismiss go 380,1 MB → 648,3→814,1 →813,6 MB.
----
Note that all the tests are performed on linux lubuntu distro with setfps 10 - the RAM drain is magnitudes smaller on higher fpses, which, combined with the stabilizing memory usage for 101 made-and-dismissed screen makes me thing that DF requests RAM space, resizes lazily unless total RAM is a concern, but keeps using same space if it is free.
This pretty much puts to rest my concerns about memory leaking with the code snippet, as long as I don't generate hundreds of screens at the same time.
Though, while they're not complete, wildly different RAM usages suggests something more is going on with my custom screens (that also interact with dfhack's keybinding, gui and probably onStateChange in the tests).
Given that, if you have enough free time handy, I'd ask you to check my code for mem leaks: tests used 101x `
testenvtester aleph beta ral` that calls on `
gui/construct-screen.lua` (whose .nonblinky_dismiss ends up being doing, like most of the code, ultimately zilch here) that calls on keybinding that can - though did not, for I pressed no keys into DF window - call on `
gui/construct_screen_execute_hook`.
At commented 800ish lines for three files to save what will be, at worst in tests, around dozen MB of RAM for a single screen, it's kind of lot of effort for small benefit. Currently, I'll probably be end up using the simple :dismiss() with perhaps nilling the C++ viewscreen in onDestroy(). (doing it the other way around, like in tests above, doesn't have the nicest interaction with menus, as nilling the base of stack also poofs all above it without error or warning.)
The point of the code is to help simulate plugin indicator screens, such as
x: additional options (DFHack) in z-status overlay. (Though, hm, not quite there yet seamlessly; only single color at one moment for one line atm, albeit you may wrap second half of line in color().)
(PS: For readers from the spacefuture of mid-september+, the links only worked for 2 weeks as to not burden pastebin.)
Author
Topic: DFHack 50.14-r1.1 (Read 892622 times)