Getting memory usage of a single widget

Getting memory usage of a single widget

Discuss Lua based Spring scripts (LuaUI widgets, mission scripts, gaia scripts, mod-rules scripts, scripted keybindings, etc...)

Moderator: Moderators

Post Reply
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Getting memory usage of a single widget

Post by Beherith »

While the profiler is nice to get the ram usage delta, I have found no way of accessing what local variables a widget has inside its own 'scope', to calculate how much ram its using in mostly table data.

Example widget:

Code: Select all

function widget:GetInfo()
  return {
    name      = "*GETMEMORYUSAGE",
    desc      = "Tries to print ram usage",
    author    = "Beherith",
    date      = "2021 Sept",
    license   = "GNU GPL, v2 or later",
    layer     = 0,
    enabled   = true  --  loaded by default?
  }
end

local BigTable = {1,2,3,4}
local IWantThisOne = true

function widget:Initialize()
	local IDontWantThisOne = true
end

function widget:GameFrame()
	BigTable[  #BigTable + 1 ] = #BigTable
	
	local ThisVariableActualllyGetsFoundByGetLocal = true
	
      while true do
      local i = 1
        local n, v = debug.getlocal(1, i)
        if not n then break end
        Spring.Echo(n)
        i = i+1
      end
end

In this case, I dont know how to get the variable BigTable, as it does not appear in the getlocal list. How should I iterate through all the variables that have been declared in the widget's scope?

EDIT: I have tried sifting recursively through all the variables returned by debug.getlocal at both stack levels 1 and 2, but BigTable is never in it
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Getting memory usage of a single widget

Post by Silentwings »

Can't remember exactly how the lua allocation (esp strings) / localization / garbage collection works, but my fast decaying memory from (re)writing the profilers is that this is impossible and not even well defined - even if it were a widget that avoided allocating memory outside of its "own" pointer tree stemming from its location in the handlers WG table (that's where the locals will be found fwiw).
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Getting memory usage of a single widget

Post by Beherith »

Ok, for the record, i did not find any locals in the wg table, only the ones explicitly exported to it.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Getting memory usage of a single widget

Post by Silentwings »

You'll need to look in the handlers tables (which iirc live inside the "real" WG - you don't want the wrapped stuff the handler exposes to non-handler widgets). The widget file is pcalled by the handler https://github.com/beyond-all-reason/Be ... s.lua#L435 as part of the widget loading, with setfenv as a table that in the eyes of the handler eventually becomes "the" widget, along with lots of other stuff (callins, etc) that is added later. The eventual insertion seems to be here https://github.com/beyond-all-reason/Be ... s.lua#L775 so probably you need to look in widgetHandler.widgets and then the array index of the widget in question (which iirc is its precedence in reverse callin execution order, coming from the "layer" parameter - probably have to search the array to find it because only the handler knows this and it can change dynamically). But my memory is pretty old, 20% chance I've just written nonsense...

Also someone added a variable that isn't in camelCase https://github.com/beyond-all-reason/Be ... ts.lua#L58 and as punishment they should be made to commit a loop that prints 100 lines of "I must remember to use camelCase".
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Getting memory usage of a single widget

Post by Beherith »

Ok, ill keep trying to dig deeper, as trying to recursively traverse all tables at a depth of 4 becomes already too large :)

Also, dont blame camelcase, blame it on someone who thought turning all map/modoptions table keys to lowercase! :P
Post Reply

Return to “Lua Scripts”