Unusual memory usage

[Benalish]

In my addon I noticed an unusual use of memory ranges from 200 kb to 1.10 mb. After several tests, I found the cause of this oscillation, located inside a function. I noticed that disabling (commenting) the other lines and leaving only this, the oscillation is still present. This function is called every OnUptate, and setting a refresh rate relatively high (about 50 sec) memory usage becomes stable.
I do not write the whole code because the source problem is only here

function buffscan()
        -- lines disabled
    local meow = { "a","b","c","d","e","f","g","h" }
        -- lines disabled
end
 
local timer = 0
 
local function onUpdate(self,elapsed)
    timer = timer + elapsed
    while (timer >= 0.75) do
        if (not db.profile["Locked"]) then
            for x, key in ipairs(db.profile["Bars"]) do
                for y = 1, db.profile.Bars[x].columns * db.profile.Bars[x].rows do
                    buffscan()
                end
            end
        end
        timer = timer - elapsed
    end
end
 
local f = CreateFrame("frame")
f:SetScript("OnUpdate", onUpdate)

[Dridzt]

You're creating a new meow table each time the function runs

If the contents of meow are static, then just move it's definition above/out of buffscan

If they're not static, then still move it above and use table.wipe(meow) inside the function to clear it and put new values.

[Benalish]

I tried this

local meow
 
function buffscan()
        -- lines disabled
     meow = { "a","b","c","d","e","f","g","h" }
        -- more stuff
    table.wipe(meow)
end

and the problem is still present

[Dridzt]

I meant this if meow is a static table

local meow = { "a","b","c","d","e","f","g","h" }
     
function buffscan()
    -- do something with meow
end

or this

local meow = {}
function buffscan()
    wipe(meow)
    -- do something with meow
end

if you need to clear it and put new values in it.

You know what :P Post your whole code or a link to a pastey with it.
It's hard to give advise when we don't know what you're trying to do, regardless if the problem is obvious.

[Benalish]

Is a DYNAMIC table

I write an example of how it should work my script

local foobar = { 
    [1] = "Welcome#To#My#World",
    [2] = "Secret#To#The#End",
    [3] = "My#Little#Universe",
}
 
function buffscan(x)
         local meow = { strsplit("#", foobar[x] }
        -- do something
end
 
local timer = 0
 
local function onUpdate(self,elapsed)
    timer = timer + elapsed
    while (timer >= 0.75) do
        for x, key in ipairs(foobar) do
            buffscan(x)
        end
        timer = timer - elapsed
    end
end
 
local f = CreateFrame("frame")
f:SetScript("OnUpdate", onUpdate)

[Kendian]

Originally Posted by Dridzt You're creating a new meow table each time the function runs If the contents of meow are static, then just move it's definition above/out of buffscan If they're not static, then still move it above and use table.wipe(meow) inside the function to clear it and put new values.

Off topic: I thought I was in SuperTroopers, for a moment~

[Dridzt]

Why are you being so difficult?

Example code doesn't help me because I still don't have the slightest what you're trying to actually do.
For that reason I can't suggest a re-structuring of your tables so you don't need to do 2 costly operations in an onupdate (strplit and creating a new table each time).

What are the keys supposed to be? Why can't you make it a hash table?

Sorry, but I'm stepping out of the thread for the moment, hopefully someone else can help.
(it shouldn't be like pulling teeth to get to your actual code, is it a secret?)

[Benalish]

As you prefer

*SPOILER* It's very very very long, can result difficult for you to read whole

http://nopaste.dk/p23585, line 373, 380 e 504

[Seerah]

That's not "very very very long".

/edit: unless it's very much longer than it should be for what it does - I admittedly didn't really read through it.

[SDPhantom]

In this post, I'll be referring to the actual code in use as linked.

Since the table tracks is registered as an upvalue already, I'll address a solution to assigning a series of values to it in the function. The way it is set up now, it's going to create a new table every time the function runs. The brackets used to define the table are actually called the Table Constructor and their entire purpose is to build a new table with the values given inserted initially.

What I suggest is to replace line 380 with the following:

table.wipe(tracks);
for i in string.gmatch(db.profile["Bars"][x][y].track,"[^#]+") do tinsert(tracks,i); end

What this does is runs a pattern-matching iterator to reconstruct the table in the same manner strsplit() would, reusing the old table instead of creating a new one each time. The pattern string I provided tells it to return chunks of the string that doesn't include the hash (#) symbol.

For more information (official Lua documentation):
String Functions - http://www.lua.org/manual/5.1/manual.html#5.4
Patterns - http://www.lua.org/manual/5.1/manual.html#5.4.1

[Benalish]

Done, but the anomalies in memory usage persist
I also made ​​substantial changes
http://nopaste.dk/p23706

[Rilgamon]

Not sure why nobody mentions garbage collect. But your anomalie is normal behaviour. Unused values, tables or functions are not removed from memory instantly. There is a process running in the background that removes the data after a while. Its called garbage collect. So for a while your memory usage increases but will drop after the next run of garbage collect.
You can force a clean up with

collectgarbage("collect")

http://wowprogramming.com/docs/api/collectgarbage

[SDPhantom]

In short, garbage accumulation and collection is a normal part of running code in Lua. However, forcing a full collection OnUpdate is taxing on any system especially at times when as much CPU power as possible is needed. This is why it's usually best to use preventative measures to ensure not as much garbage is generated too fast. A handful of kilobytes a second is normal, but if you're going through hundreds of them a second, there's a little cause for concern.

[Torhal]

If you find yourself needing to use collectgarbage(), chances are you're doing something very wrong.

[Rilgamon]

Thats why I used the word "force"

[SDPhantom]

Reiterating

Originally Posted by SDPhantom However, forcing a full collection OnUpdate is taxing on any system especially at times when as much CPU power as possible is needed.

[Resike]

Originally Posted by Benalish As you prefer *SPOILER* It's very very very long, can result difficult for you to read whole http://nopaste.dk/p23585, line 373, 380 e 504

I think admins here can deal with 500 line codes. :P