So what do you do when your game starts to get slow? I have a particular command that’s very slow, and looking at the rules that run during the action, it seems like hardly anything is happening. Is there some way to get deeper than “rules” to see what’s really going on? Is there some way to turn on I6 debugging messages, for example?
I first use RULES ALL because even unexecuted rules take time to consider whether or not they apply, and if you have descriptions in the preamble like examining “someone suspicious” then there’s at least one hidden loop right there. While one or two of those don’t make much of a difference, they can add up. Every Turn rules, printing the name of rules, does the player mean rule, before & instead rules, all are considered frequently.
If you’ve narrowed it down to a single rule that’s being slow, then I suggest just inspecting the phrases within. Inform 7 is really good at hiding loops. Can you add a “let” variable to remember the result of a loop so it needn’t be looped again? That sort of thing. Is recursion occurring anywhere? Any “topic is listed in table” preamble loops? How many rules does a simple LOOK consider (not necessarily execute)? Etc.
RULES ALL didn’t turn up anything new. There is a loop in one of the phrases, but it’s a loop that also runs several times in an every turn rule, and other actions (such as waiting, ironically) aren’t slow at all.
I’m wondering if the hangup is actually happening during parsing. There’s a conditional understand line that might be slowing things down, but I don’t know how to be sure that’s the problem, and I don’t know how to speed it up:
[code]Specimen absence relates a multitude (called the set) to a thing (called the element) when the element is the specimen of the set and the element is not visible.
Understand “[something related by specimen absence]” as a multitude.[/code]
Yeah, that looks like it. I commented it out and everything went much faster. Maybe I need to write that scope-caching extension.
Oy vey. I now have a shell script that runs test commands using glulxe, but it takes about 40 minutes to run one of the more involved tests. Which is weird, because it only takes a few minutes in the IDE (less than 10, but I wasn’t watching).
So it looks like Zoom and glulxe don’t have high-level profiling tools, I need to write the commands into my source? I tried profiling Parchment Transcript with Firebug, but I don’t know how to read the output or send queries to the console.
No, it’s all good - I have real names now. And I figured out what @glk_$c0 must be - it’s the function to wait for input. I piped a list of commands to glulxe so I could skip that step and I got some more reasonable-looking results:
(Yes, @glk_$c0 is glk_select(), which is waiting for input.)
Those are all low-level library and veneer calls, of course. If you dig farther down the list, you may be able to find functions corresponding to I7 rules which are taking a lot of time, which are the parts of your code you’d want to focus on improving. These will have low “executing” times but high “including child calls”.
But, sadly, these will have names like “R_925” and you’ll have to look at the auto.inf file to figure out what they really are. Also, I never developed the profile-analyze.py much, so digging through the list requires you to use the “-i” option and then print out Python data structures.