Tracking increasing resource requirements

[DavidGriffith]

Are you guys tracking how your changes impact how much resources a compiled program consumes?

[fredrikr]

We don't have any benchmarks over time, no. When we see a change we could make which we know will make the code both smaller and faster, we just make it. When a change will make the code a little bigger but also faster, we evaluate the performance gain and weigh it against the difference in size. Sometimes we just do a rough estimate based on the number and types of instructions that will be executed, sometimes we measure execution times in Ozmoo.

Also, we want a good, solid library that makes adventure authoring fun. Sometimes we add stuff which we think was missing, and it just adds size to the library, like when we added new ways to shout at things/people. And a few days ago we added 100 bytes to the parser to remove duplicates from lists, like when the player types "get book and glass and book". But then we found a way to shave off 70 bytes at no performance cost in another part of the parser. And so it goes on.

We have a rough idea that a minimal build of the library should definitely be < 30 KB in size, and preferrably < 25 KB. It's currently ~23.5 KB.

[Kroc]

You could perhaps include the current minimum library size in each release note; this would be useful over time even if not useful in the immediate.

[fredrikr]

We talked about it, and we think this would give the false impression that out primary focus is the compiled library size, and that size would be seen as some kind of measurement of the current quality of the library.

Our overall aim is really two-fold: (A) Create a good, solid, powerful library that's easy and fun to use. (B) Make the library fast on 8-bit computers.

To reach goal A, we

• add funcionality, sometimes optional, always compact
• fix bugs, which often increases the size of the library

To reach goal B, we:

• optimize code for speed (use fewer instructions and prefer faster instructions)
• make the library code compact when compiled (use few instructions, a compact library message system and reuse library messages)
• order the library functionality so that large chunks that are rarely used can be swapped out by the virtual memory handler
• make parts of the library optional
• use the best abbreviation algorithms we can

While keeping the library small is important, it isn't actually one of the main goals. It's just one of the means to reach one of the main goals.