Indexed text, and progressive slowdown during play

I love indexed text. It’s a great tool for adding little bits of random interactive detail to the game world. But I’m beginning to understand why some people go out of their way to avoid it.

The game I’m currently writing runs painfully slow, so I decided to run some tests to quantify how long different operations take. For indexed text, I found that it’s not only slow – which I expected – but that it gets progressively slower as the game runs, even if the total amount of indexed text currently in memory remains small.

Specifically, the loop:

Instead of pushing the green button:         [For testing, not part of the actual game.]
	let t be some indexed text;
	repeat with n running from 1 to 10000:
		now t is "abcd";

takes 4 seconds to run the first time the player hits the green button. Hit it again, and the loop takes 10 seconds. Then 26 seconds, then 50, then 79 and then 105 seconds.

(By contrast, if you remove the word “indexed” and run the loop with a regular text variable, it takes half a second, and remains the same no matter how many times in succession you run it.)

This is all on Glulx with standard memory settings. Note that the loop isn’t filling up more and more memory with indexed text; it’s overwriting the same four-character string into the same variable over and over.

Is there an existing guide out there to Inform’s memory management in general, or to indexed text management specifically?

Are you doing your testing in the Inform editor? IE in test mode?

Because of the extra degrees of internal testing that go on there, the game will run slower than it would in ‘real life’ (wags fingers) - IE out in an interpreter.

Still, I’m surprised to hear something would take longer each time you do it, in any venue.

good catch, release mode is much faster
…still…anyone up to helping me add ‘compile to c’ flag to the i6 compiler? im scared to wander there alone…

I see this slowdown in the Mac IDE, but not in Quixe, nor in Glulxe when compiled with cheapglk or glkterm. (I tested both the original Mac 6G60 release and the recent Lion fix, although this Mac does not have Lion on it. Same results.)

Are you also using a Mac? If so, this strongly implies a memory leak in the CocoaGlk library.

I like the idea of output filtering, which would require indexed text, but you can do quite a lot with say phrases. I was playing with this the other day:

[code]Report praying:
Carry out the speaking out loud activity with the noun;
unless able to speak clearly:
say “Or at least that’s how it goes in your head. The actual sound you make is more like [italic type]’[random sputter].’[roman type][paragraph break]”

To say random sputter:
say “[one of]F[or]P[or]Aa[or]G[at random]”;
Repeat with i running from 1 to 8:
if a random chance of one in 3 succeeds:
say " [one of]frm[or]th[or]cl[or]fu[or]bl[or]g[or]h[or]a[or]u[or]n[at random]";
say “[one of]l[or]k[or]r[or]vf[or]a[or]gh[or]th[or]yr[or]rh[or]t[or]bl[or]ghh[or]h[or]u[or]uh[or]n[at random]”[/code]