C_Map.GetPlayerMapPosition Memory Usage
Anyone else having memory issues with C_Map.GetPlayerMapPosition? I updated some map coords code to use the new functions and noticed that the addons memory usage grows every update. By commenting out other code I was able to narrow the problem down to this function so I know it is the problem. I had it setup like this.
Lua Code:
and also tried this. Lua Code:
I also tried moving the variables outside of the function but nothing changed. Anyone know how to fix this. The addon worked with no issues with the old functions on live. |
It's just how Lua handles tables, and it's been a constant issue I've had with Blizzard's trend with their APIs lately. Every time an API is called that returns a table, it takes up a small chunk of memory. This can add up quickly, especially in combat log events and OnUpdate. It doesn't matter if you assign it to a variable or not, just the act of calling the function does this.
Specificly, C_Map.GetPlayerMapPosition() is generating this new table every time it's called. The memory eventually gets freed when Lua determines it needs to, but it's bad practice to rely on its garbage collection as it can cause random lag spikes. |
Lua Code:
|
Code:
local mapID, position |
Lua Code:
mapID can be undefined while using portals. |
Lua Code:
|
This is getting off topic. The discussion is how to counteract the memory impact of calling C_Map.GetPlayerMapPosition() frequently.
|
Arguments are reserved(?)
In the old days of scanning for nameplates JamPlates used the method of declaring variables as arguments to reserve memory.
Edit: Think there was a misunderstanding. The global function was localized because it bothered me. Lua Code:
|
That's just localizing the function, because local functions are something along the lines of ~25% faster than global functions in terms of executions.
The problem with map position is that some position-tracking addons uses it OnUpdate which was fine when it was two simple numbers. But the new API causes that code to create a new table every frame. Sure, those tables end up being collected as garbage sooner or later, but it's rather annoying and may scare users into thinking something is wrong with your addon. |
Blizzard dev who created those API's said to not worry about memory usage.
|
That's the point though, it's not just memory. When the garbage collection is called more often, it eats up cycles and becomes a CPU problem.
|
I never said anything but just so it clear to everyone the function that elcius posted works well.
|
Does anyone know how to scale the worldmap properly?
If you just simple SetScale, you won't be able to switch zones by click on different part of the maps. |
Quote:
Code:
WorldMapFrame.ScrollContainer.GetCursorPosition = function(f) |
Quote:
|
Quote:
If you are extremely worried about the memory consumption from the Map APIs, you could use my Map library HereBeDragons which offers table-free position APIs (althought thats not the reason I made it that way, its just the same API the library had in 7.x already) - and no, it also doesn't just wrap the Blizzard Map API to "hide" the tables. :) |
I found this in LeatixPlus by using "RunScript", and it does not produce memory waste.
Code:
local pTimer = 0 |
That's way worse. It's just not attributing the memory usage to the addon. Now it's spending time lexing and compiling the string into byte code, which then becomes garbage. And then you pay the same price for the C_Map.GetPlayerMapPosition call.
|
Quote:
Memory usage is not an issue. Having giant tables of data actually saves cpu, especially if you’re not calling things in combat. One fine example of memory/cpu efficiency is Details. In terms of combat FPS, Details clearly, objectively, wins over Skada or Recount. Memory waste is bad. An occasional wasted object is sloppy but not usually an issue. However, dumping a table every frame is what we call a “memory leak”. Lua’s garbage collection is the least efficient part of the entire implementation. It’s like a garbage inception. You want to avoid it at all costs, but with hundreds of different addon authors, it’s inevitable. A blip in FPS every hour or so is fine, maybe every 30 minutes if I’m running a bunch of addons, but memory leaks trigger one every few minutes, as often as several a minute. Having Blizzard give you a function that directly generates waste every time you use it for data that several addons want on an OnUpdate resolution is probably the worst thing any Blizzard dev has ever done for this game. It’s atrocious, disgusting, reeks of novice coding. I have enjoyed all the mixin stuff I’ve seen popup over the last few years. Someone on the dev team has lots of love for Lua. I sincerely hope these wasteful issues were an oversight, a bug, or done from someone new that will be fixed by someone senior. |
Quote:
Please, go ahead and do show incontrovertible evidence without manually interfering with the garbage collector, then we can continue. All these arguments are grasping. |
All times are GMT -6. The time now is 01:18 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI