Should I be concerned about performance?


#1

I’ve heard about some inform games performing slow on mobile devices, and as a programmer it does bother me when I type something fairly general, knowing I’ll never need it outside of that room, and wondering; will Inform will be processing this condition with every single thing the user types? Also that may open up opportunity for bugs when this condition is applied to something I didn’t expect it to be.

Is there ways to type things that tie them programatically to certain locations, or maybe section off bits of code to only be processed per room, something like that?

Or is this generally never a problem?

I’ve searched around the forums and the web and haven’t found anything specific yet…


(Daniel Stelzer) #2

Generally this isn’t a problem. Look at Hadean Lands and Counterfeit Monkey, two of the largest IF games ever made, both in Inform 7, and both run well enough on mobile devices (with certain optimizations that most games never need to worry about).

What sort of code in particular are you worried about?


#3

Nothing yet, I just didn’t want to embark on a huge undertaking and then have to re-write it all later down the track :slight_smile:

But if everyone says there typically isn’t a problem, I won’t worry. I suppose I would have found more info more easily if it was more of a problem.


(Andrew Plotkin) #4

The tricky part about performance in I7 games is that you can write slow code without realizing it.

Obvious conditions are obvious: an “every turn” rule is evaluated every turn, but “if/when in Room X” is a fast test so you can condition off chunks of code. A lot of fast “if” conditions every turn aren’t a big problem. But one relation test might be expensive – or not, depending on the test. Optimizing I7 is really a pain in the ass and requires some deep knowledge of the code at the I6 level.

The flip side is it probably won’t be a serious problem unless you write a very large game and release it as a mobile app.


#5

Thanks zarf!

BTW I found the page again which mentioned the slow performance on mobile. It was 7 years ago, perhaps the average mobile phone speed these days compensates for the issues this user was talking about?

It’s the last post by S. John Ross in this thread
groups.google.com/forum/#!topic … svLQvGvR40


(Ruber Eaglenest) #6

Is there any guide about optimising I7 games “by hand”? Maybe a thread of tricks to do that.


(Andrew Plotkin) #7

People ask periodically, but I’ve never found a good general answer.


(Hanon Ondricek) #8

In most cases, text is efficient and with the glulx standard, most people rarely run into performance or lag-causing problems unless you’re doing something bizarre. If you’re wanting to do something like 10,000 procedurally generated rooms that rearrange themselves every turn or a large number of relations that apply to every object in the game…that’s when you need to be concerned with performance. Most authors won’t run into that. Occasionally in large games with lots of dict_entries or many new verbs, you’ll need to bump a few limitations that are set for memory economy, but Inform will let you know when that happens and it’s easily done.


#9

If performance is a serious concern for you then it might be best not to rely on “high tier languages”. Of course that would also mean that you’d need to put in a lot more effort because then you’d have to set up many things manually for yourselves.

Still, another thing which I can’t help wonder about: the amount of influence the player / interpretor will have. I can’t back this up with facts because I’m only familiar with Frotz (which is good enough for me, so I really don’t feel like trying) but I could well imagine that other players (if those exist) might handle these source files in another, maybe more efficient, way.

Food for thought perhaps?


(Andrew Plotkin) #10

No, all interpreters execute Inform code the same way.

Some interpreters run faster, because they’re better optimized internally, but they’ll faster by about the same factor on all game code.


(Daniel Stelzer) #11

That said, there’s a really weird mechanism in Glulx where interpreters are allowed to optimize certain parts of the Inform standard library. An interpreter which has these optimizations versus one without would probably show rather different runtimes for a big Glulx game.


(Andrew Plotkin) #12

I think all the interpreters have that by now, so I didn’t want to get into that level of detail. :slight_smile:


(Daniel Stelzer) #13

Fair enough. I wasn’t sure how ubiquitous that was. (Or, for that matter, if it even helps at all in I7, which uses a heavily modified I6 standard library.)


(Björn Paulsen) #14

This mechanism intrigues me, and I wish to know more.


#15

https://www.eblong.com/zarf/glulx/glulx-spec_2.html#s.17
https://groups.google.com/forum/?fromgroups=#!topic/rec.arts.int-fiction/FIIdUPhsWy4

Note that this is not accelerating anything in the Inform 6/X library - it accelerates the most commonly used routines in the Inform 6 veneer layer, which is built into the Inform 6 compiler, and provides a number of core functions in terms of Glulx or Z-Machine opcodes.


(Björn Paulsen) #16

Thank you!


(Daniel Stelzer) #17

Ah, I misunderstood this part! Accelerating the veneer makes more sense, certainly.