docks.dmp - 7.13 KB (bearing in mind that this doesn't include the trees which are generated at runtime)
1,0.map - 226 KB
As soon as good reasons can be given for how a savefile consisting of 80x80x2 turfs (written as a pair of 6400-character strings of single-byte text characters, with no turfs written directly to the savefile) and 1782 objs can take up 226 KB, I'll embrace it. [edit]I had written 1882 earlier, but realised that 891+891 (since I was saving the same map twice to test it out) is not 1882. I suck at math.[/edit]
I mean, hell, even the savefile/ExportText() of that savefile is only 154 KB!
I've deliberately avoided DMP saving because it's so inefficient, but come on. That kind of wasted space is just ridiculous. If I can get it down to less than 5% of the space just by using DMP saving, I'm going to save DMPs.
Further experimentation reveals that it's definitely the objects to blame. 226 KB shrank to 12.6 KB when I stopped saving the objects. Objects are only saving their type, their x coordinate, and their y coordinate (verified explicitly via ExportText()). Somehow, this means that there is approximately 113 bytes (!!!) per object saved! Compare that to what I figure should be at most 4 bytes for the coordinate plus 1-4 bytes for the type, which would refer to an internal type table contained in the savefile instead of saving the exact same object path in full form for every single object.
I've already gone ahead and written a heck of a lot of code to save and coordinate terrain by text symbols (the aforementioned 6400-byte string is human readable when exported from the savefile), but now I'll have to write even more code to use numeric IDs to refer to objects' types!
We need binary saving and loading in DM and we need the option of using strict data types in our programming. 226 KB of bloat, a realtime variable that's accurate to only two minutes, and an eight-second load time to load 1782 objects into memory is positive proof of this. There's just no good excuse for those any more.
Dec 14 2006, 8:59 pm
|
|
Elation
 |
You told them good.
|
I agree. Saving maps is a waste of time unless it can be done properly, with ease, and using as little space as possible.
| |
Yeah, the ineffeciency of the dmps really blows my mind once you start adding objs to the mix. I started just saving objs to a separate file and loaded them from that at run time. Saved load time and space.
| |
What is this ".map" file of which you speak?
| |
The objects and stuff.
| |
DMP saving isn't that great, I do it so I can build my maps in game, But for a 250x250x4 map it takes 45 seconds of lag.
| |
The .map is a standard BYOND savefile with a structure as follows:
"surface/terrain" = 6400-character text string corresponding to an inverted ASCII map of the surface (i.e., bottommost rows appear first in the string) "surface/objects" = BYOND list of instances of objects, written directly to savefile "burrow/terrain" = 6400-character text string similar to surface map (exactly similar for the purposes of my test) "burrow/objects" = another BYOND list of instances of objects, again exactly similar to the surface map's objects list for purposes of the test There were 891 objects in each list, and somehow those 1782 objects put together swelled the savefile from 12.6 KB to a whopping 226 KB. I'm guessing the savefile saves directory information and type path information for every single instance in the file with no concern for hard drive space or read efficiency. This could be handled so much better if it used a look pointer instead of just reading the whole savefile into memory, as I'm fairly sure it does right now. Each object, exported from the savefile, looked something like this: .28 type = /obj/tree save_x = 48 save_y = 1 | |