Slow compile with a lot of "if" conditions

Authoring Inform 7
1

I noticed that my compile time increased by a huge amount (factor of 10?) when I had an “if” statement with a lot of conditions, like this:

the fork is a thing.
fork has a number called b1.
fork has a number called b2.
fork has a number called b3.

instead of examining yourself:
    if (b1 of fork is 1 and b2 of fork is 5 and b3 of fork is 3) or (b1 of fork is 3 and b2 of fork is 90 and b3 of fork is 100) or (b1 of fork is 3 and b2 of fork is 1 and b3 of fork is 8) or (b1 of fork is 4 and b2 of fork is 5 and b3 of fork is 2):
	say "Special fork state.";

Hopefully this doesn’t come up often, but I thought I’d mention it.

I have Windows build 6L38.

1 Like
2

Huh, interesting. Do you know which phase of the compilation it’s slowing down in? (There’s a tab for compiler output you can look in.)

3

It seems to hang up between

“I’ve also read English Language by Graham Nelson, which is 2288 words long.”

and

“The 415-word source text has successfully been translated into an intermediate description which can be run through Inform 6 to complete compilation.”

1 Like
4

Is it any faster if you split it up manually into nested ifs? I’m not trying to troubleshoot, I’m just interested.

Also, you asking programming questions is hopefully a sign of things to come… :grinning:

5

Yes, it’s pretty easy to work around. In the example above, I can just write a series of “ifs” that each do the same thing.

6

I had a similar thing happen when copying some code from Delightful wallpaper. It has a big list of conditions for being immaterial, like “Instead of dropping or touching or pushing or…” and when I added it in, the game slowed down a ton, but not when I split it up.

7

Huh, interesting. That to me implies that the part of ni that handles conjunctions is having some problems. Unfortunately, that’s not something we can debug or fix without the source code; for now, breaking it up is the only real solution.

1 Like