ID:2374808
 
BYOND Version:512.1426
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 67.0.3396.62
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
TurfsDatums that have a user defined var overridden in a child type see more memory usage when created at runtime (such as by editing world.maxz) even though the vars are never modified from their compile time value

Numbered Steps to Reproduce Problem:
compile test project.
run test project in dd
press control + m

Repeat but add a return to the top of world/New()

Repeat but uncheck barebones.dm and check barebones2.dm


Code Snippet (if applicable) to Reproduce Problem:
https://tgstation13.download/turf%20memory%20usage%20bug.zip

Confirmed on 511 as well
Okay, I've been looking at this and the results are not what I expected.

As it turns out, I don't think this behavior is actually a bug. However I want to leave it here instead of moving to features because I think it's a big enough deal I'd love to figure out a way to avoid this problem.

What's happening is that all protoobjs have var_defs, var_list, and hard_var_list. The last one is used for some special stuff like client vars, special vars like bounds, etc. var_defs contains only the newly-defined vars on an object, not its overrides; each of those has a var ID and an entry in the global defvarA array that contains the default value.

var_list has all the other vars, like subtype overrides, and those vars are set at runtime on object creation. In other words, my previous understanding that any obj that does not explicltly override a var doesn't use extra memory to store it was totally wrong. It's probably true of vars that haven't changed at all, even in a subtype, since their original defs, and it's true of most appearance vars regardless, but it's apparently not at all true of user-defined vars that have been modified since the original def!

What I believe I'll have to do is modify the routine that optimizes var_defs to simplify lookups, and give ProtoObjs a new list that stores their default vars. ProtoObjGetVarDefaultVal() will have to change, and also GetSoftObjectVar() as well. (Also InitObjectVars(), which actually sets the vars from var_list.) This is a bit of a mini-project but it has the potential to do very nice things to SS13 memory use, so it's high on my to-do list.
The fact that it doesn't happen on maploaded turfs suggests the fix is easier then you think.
In response to MrStonedOne
MrStonedOne wrote:
The fact that it doesn't happen on maploaded turfs suggests the fix is easier then you think.

It does happen on maploaded turfs. In PostLoadMap(), InitObjectVars() is called for each turf which is what also calls the turf's init procs (if any).
map: 391248 (255,255,1)


No it doesn't.
I can explain the discrepancy. It took me a bit to figure it out.

When I leave in the code you have in world/New() that sets maxz to 0 and then changes it to 1 again, I don't have the map-loaded turfs anymore but instead the default /turf/open/space/basic. That explains why I saw a higher number.

When I commented out that code so the map was used, I saw that all of the turfs were type /turf instead of /turf/open/space/basic. The latter, and its parents up to but not including /turf, has all those var overrides. Your /turf definition only defines new vars or alters appearance-related vars; it does not override earlier user-defined vars, like /turf/open/space/basic does.

Thus, your map-loaded turfs are taking up no var memory because /turf has an empty var_list. But /turf/open/space/basic and its parents /turf/open/space and /turf/open do have var_list values defined.

If you changed your map to all /turf/open/space/basic, you'd see all of those turfs using var memory even though they're map-loaded.
oh ya! the dmm was made when world/turf was still the default /turf