Question: I’m trying to shrink the memory footprint of an extension, so I compile two versions of it, Plan A and Plan B. I compare the sizes of the resulting .z8 files using the command line, but they’re the exact same number of bytes for both plans! What the hey? I thought it was my filesystem playing tricks on me, but Windows and Mac both do this. But the resulting sizes cannot be the same. In one case I turned a single-column I7 table into an I6 array. The array method should be smaller – it lacks header bytes, lacks a parallel “blanks” array, lacks a lot of auto-created debugging information, etc. But the .z8 filesizes per the “ls” or “dir” command are precisely equal.
What am I missing? Is there maybe an interpreter that can give me some details about what’s going on here?
Is it possible that all the extra memory usage happens at runtime? There was something about that in the last discussion of measuring memory usage, and the result was a uservoice suggestion for a runtime memory report command.
Header address $0e well tell you exactly how much dynamic memory is used. I suspect Inform 7 is making up the reduction with something else, maybe a larger heap for example.
Z-machine files are rounded up in size to the nearest 512 bytes. (Infocom did this to make their page-swapping interpreters easier to write. Actually I’m not sure Infocom always did it, but I6 always does.) (In Glulx, I made all the memory boundaries multiples of 256, for simplicity and in case anyone cared.)
No, for Z-code that’s impossible. The compiler pre-allocates a large buffer and that’s it.
If you want to know the memory layout in more detail, re-run the I6 compiler on auto.inf and include the “-z” flag. It’s not super-explicit, but it shows how much memory goes to array data, object properties, and a few other categories.
For posterity (and in case I lose it) this is what I entered in the DOS prompt and got back. Know that the switches are “p” for percentages (the final part), “s” for statistics (the first part), “w” to not print those 1400 warning messages, and “z” for the pretty map.
I tried with the Release versions of both, and got similar results. I would’ve expected the I7 version to shrink some in that case anyway, but it didn’t. Presumably the Use Memory Economy option would’ve removed the ability to print table names, maybe?
After further digging, I think I did find out why the I7 was smaller than the I6. Observe the I6 code, which is just part of the extension:[code]To decide which text is the pronoun corresponding to (decl - a declension) in (gcase - a grammatical case): (- CorrespondingPronoun({gcase} + {decl}) -).
Include (-
[ CorrespondingPronoun decl_case;
(+ the prior named noun +) = nothing;
return declensions–>(decl_case - 1);
];
Array declensions --> “I” “you” “he” “she” “it” “we” “you” “they” “me” “you” “him” “her” “it” “us” “you” “them” “mine” “yours” “his” “hers” “its” “ours” “yours” “theirs” “myself” “yourself” “himself” “herself” “itself” “ourselves” “yourselves” “themselves” “my” “your” “his” “her” “its” “our” “your” “their”; -).[/code]
It’s the strings. I7, when finding a piece of text that’s identical to another piece of text, will include it only once and have both places point to it with a name like SC_178. When the text is included via I6 inclusion like the above, it cannot do this, so loses the opportunity to merge them. When I changed the array to numbers, I got more sensible results.
