I used 5/8 as a approximation because I didn’t think your points would affect the size that much but maybe they do (especially your first point). Zilf doesn’t report these figures but it should be possible to extract the correct numbers from my abbreviation finding program. I’m gonna recalculate and report back!
1 Like
Looking at the PunyInform z5 version, 41832 charactes of text is stored in 31554 bytes. If it was as simple as multplying by 5/8, it would be 26145 bytes. As far as I can tell, this 5 KB difference is all due to points 2-4. So these points actually make a big difference.
I’ve checked now, and point 5 (alignment waste) is not included in the bytes reported by the Inform 6 compiler. Craverly has 498 high strings, giving us an additional waste of ~750 bytes.
I’ve recalculated and the ZIL z5 version have 40.737 characters of text that is stored in 30.622 bytes without abbreviations and 22.254 bytes with abbreviations. The updated table below.
Size without abbreviations 55.832 bytes
Text size (characters) 40.737 bytes
Text size (z-chars) 30.622 bytes (75.2% of size in characters, 54.8% of z5-file size)
Size Z-code 25.210 bytes (45.2% of z5-file size)
Size with abbreviations 47.464 bytes
Text size (z-chars + abbrev) 22.254 bytes (54.6% of size in characters, 46.9% of z5-file size)
Size Z-code 25.210 bytes (53.1% of z5-file size)
I guess that the biggest extra cost that I missed are all the uppercase letters that use 10 bits for each character.
1 Like
Would it make sense for the compiler to leave the abbreviations out if you’re not using the -e switch? (I can’t see why not, but I might have missed something.)
The “characters used in text” line (from -s output) includes strings, LowStrings, and object names. The “bytes compressed” line is the z-character equivalent of that text. It includes wasted bits but not alignment padding.
I think it would make a lot of sense. I don’t think it’s possible to refer to these strings (except maybe with some low-level Z-machine hacking), so it’s just wasted space.