How safe are I7 lists in terms of memory usage? Are they safer than indexed text?
Inspired by the discussion on tracking NPC knowledge, I’ve been thinking about changing the Multitudes extension to use lists instead of one big table, but I wanted to check whether how that would affect memory usage and stability.
I would also be interested in knowing how lists compare to tables with regard to speed and performance.
(I’m not sure what you mean by safety/stability, though–I’ve not seen or heard of any issues with either indexed text or lists in this regard.)
–Erik
I was under the impression that indexed text could crash a game if it took too much memory. Maybe I’m wrong.
Lists and indexed text both use the code for managing multiblock values, so they are on the same footing in that regard. For Z-code stories or Glulx stories on interpreters without @malloc they could both cause you to run out of memory at runtime. But it depends on the circumstances, and in many cases it’s not something to worry about.
The block value management associated with lists means that they take more memory per element than tables do, but on the other hand they grow and shrink with their contents; you only pay for the data that you store. Similarly, lists are generally slower—depending on your usage pattern they can be far slower.
Edit: That’s not to say that you shouldn’t use lists. Other factors are important too, like how easily the code can be read, and the fact that lists don’t have a fixed size limit.
Thanks!
I was hoping that using lists instead of tables would speed things up, because every room has a separate list, and all the lookups are done by index - as opposed to a table where a row has to be found with two matching columns.
Unfortunately, the game seems to run just as slowly with lists, and you might have given some of the reasons why.
The curious thing is that when I do “rules,” it looks like there’s only one rule that runs during the slow command, and it’s one that I would expect to be running multiple times during every turn rules - and yet most turns don’t take that long. I have no idea how to figure out why it’s so slow.
Maybe I’ll use the table acceleration code that someone recently pointed me to…
Thanks, Emacs. Just speaking anecdotally, I think the way lists are used, which you mentioned, must be the crucial factor, and some interpreters may also be speedier than others. For Glimmr, I implemented the glyph map for entire bitmap fonts (i.e., “pixel fonts”) as a single list (see here). Printing each glyph to the screen requires a series of table lookups, then a series of seeks through a very long (2500-3000 entries, I think) list to draw each pixel/bit. You’d think it would be exceedingly slow–I wasn’t sure it would be usable at all when I started working on it–but in Gargoyle, printing text to a graphics window like this seems about as fast as printing standard text to the buffer window, at least for a moderate number of characters! (Other interpreters like Zoom and WinGit are also pretty fast, but they may be slower, either at drawing to the screen or at block value access. Quixe is another matter; I have no idea how well it would perform when faced with a similar task!)
I’m not sure how widely these results are valid–I’m sure that it is the case that lists are (or at least can be) slower to use than tables. Ron mentioned lists of lists in another thread as particularly slow, for example. But my lonely anecdote does seem to indicate that, at least for simple one-dimensional operations, lists in themselves don’t necessarily have any particular performance downsides.
–Erik