Surprisingly areas don't appear to play a significant role in this, but turfs do. You have lots and lots of unique turf appearances. I'm trying to tell now if the number of cells is simply growing too fast for the garbage collector loop (because it doesn't use reference counting), or if it's too high period. If it's the latter, I'll need to think through some options. If it's simply that growth is outpacing garbage collection, I have a sanity check that should help.

[edit]
Your map appears to be the biggest driver of this. The number of unique appearances in it is staggering. You said you had a 300x300 map, which wouldn't be likely to come anywhere near the limit at all; I don't recall you saying anything about it being 300x300x28.

Incidentally, it looks like you can save yourself a crapload of startup time by making sure most of your turfs have default icons, like for instance the grass turfs should probably have icon_state="a" unless otherwise noted, and you can remove those (via a text editor) from your map file. The way map tiles initialize values like this is via an init proc, so a lot fewer of those would have to run.

My sanity check does appear to have prevented a problem at startup with the weather system on. It will probably avoid issues in the event of rapid changes and may well be enough to avoid future problems. But wow, your is skirting really close to the limit on this one.

I might have to consider raising the number of unique cells, but I think the only way I can do that and keep performance high is to double the size of the main map array. In spite of a lot of wasted space in its current 4-byte form, it'd waste more as 8 bytes; but if I just used bit tests to try and pack it better, I think the performance would suffer. Alternatively, I may have to consider using separate arrays.
Is this happening because when we map we use the generate from icon-states feature? How would I use text file editor to remove them form the map too?
First I would make sure your grass turf has a default icon_state of "a". Then in a text editor, replace /turf/grass{icon_state = "a"} with /turf/grass (and so on for all /turf/grass subtypes).

This will not influence the number of unique map cells, but it will reduce load time by avoiding init procs on any /turf/grass with an icon_state of "a". Your load time is substantial so any boost you can give it would help. Likewise you'd want to do the same for any type that had the same common icon_state reused a lot.
First I would make sure your grass turf has a default icon_state of "a". Then in a text editor, replace /turf/grass{icon_state = "a"} with /turf/grass (and so on for all /turf/grass subtypes).

This comment is relevant to my interests.

http://www.byond.com/forum/?post=1620724

The hard-coded prototype way completely violates any form of reasonable project structure, Lummox. Environment artists absolutely should not be using code to specify static visual data.

Ideally, the existing DMM format should probably be ditched entirely in favor of something less cumbersome if using the prototype editor as documented in the guide (and intended by Dan, which I've thoroughly pulled documentation from 1999-2001 that seems to indicate that Dan fully intended the map editor to function like I outline here in this post.) seriously affects us that much.
In response to Lummox JR
That would be sort of an issue. We have 8-9 grass iconstates, for edges etc and they're alll produced using the generate from icon states feature. Edges, etc.
Yeah, Ter, I think you're right. At a minimum it seems like it'd be reasonable to create invisible subtypes or something like that, or at least find a way to only run the init proc once per special type.

While investigating this, I did find that the map cell hash is kind of slow because it was only designed for 256 slots, which is a heck of a lot of collisions considering you can have up to 64K unique cells, so I bumped that up to 1024 hash slots and may yet go higher. (Considering it's 2 bytes per slot, it's probably trivial to go higher.)

Because it seemed reasonable to do so, I split up the worldmap array into two distinct types so the "has contents" info is now its own array, which means I'm no longer constrained by padding. (Hopefully it also means the contents check will be marginally faster, but I don't know.) This means I could bump up the map cell limit beyond 64K with only a 25% increase in map memory compared to current usage. (Honestly I wish I didn't have to worry about it and could pack everything into a 4-byte struct, but I think performance matters a lot more.) If I don't bump this, though, we're looking at a 25% reduction in memory usage compared to previous versions.
Page: 1 2