[i7] story file size: lists vs tables

Authoring Inform 7
1

I noted from this topic that tables are less memory intensive than lists and hence probably help a program run faster.

https://intfiction.org/t/whats-the-least-memory-intensive-data-structure-in-i7/1859/1

However, I was surprised to find that tables also take up less disk space–or seem to, based on my compiling this code for release.

[code]“pgs” by Andrew Schultz

room 1 is a room.

[table of junk
mytxt
“aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”
“a”
“a”
“a”]

junk is a list of text variable. junk is {“aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”, “a”, “a”, “a” }
[/code]

I alternatively commented out the table and the list, and I got the following file sizes for release builds:

Z5 tables file = 243134
Z8 tables file = 248254
Gblorb tables file = 324542

Z5 list file = 290752
Z8 list file = 296382
Gblorb list file = 421822

So the main question is, I’d think the reverse is true, that a long table entry would cause inform to allot more disk space to each table row, though I don’t know much about that. Is there a simple layman’s explanation?

Also, to apply this, my lists are generally static–I shuffle them randomly at the beginning of play, then let the player randomly page through them. I never need to insert or remove elements. There are 25 lists and about 3000 random items.

Would there be reason to believe that converting these lists to tables would make the program run significantly faster? (editing the code would not be bad with perl.) And have I, thus, been using the wrong structures all this time?

2

If you don’t use lists or indexed text then the whole heap system doesn’t get compiled. I can’t remember what the base size of the heap is, but I think it’s 4096 words, or 8KB for Z code and 16KB for Glulx. In addition there’s a lot of code that gets excluded.

Tables are fixed size and so the code is much simpler. The code can use simple array indexes rather than needing to figure out where in the heap the data it needs is. So are probably usually faster. Or depending on what it is that you’re randomising, sometimes just asking for a random object would be even faster.

3

The underlying data use is the same – a single-column table entry and a list entry both take one word. (Two bytes in Z-code, four bytes in Glulx). The table and the list both have a little bit of overhead, but it’s not very important.

The difference, as Dannii says, is that the compiler sets aside a lot of space for list manipulation if your game includes any lists or indexed text. Table manipulation never requires extra memory.

4

Thanks for the explanations!

I’ll be using a huge chunk of indexed text, so the list manipulation space will be reserved in any case. Still, just knowing tables aren’t any worse is a bit help in many ways.

The use case is shuffling, say, 100 bits of random text and tacking on a “I’m cycling again” text to the end, so one of/or isn’t quite appropriate.

Before, I was just adding something to the list at the start of play, but checking for the end of the table is really just as easy.

The other nice thing is that I can make a table where one row points to tables, but I don’t think Inform lets me use a table of lists–this is largely architectural, but it cleans up code elsewhere.

And it’s good to know for the future.