Follow-up: Revisiting verbosity based on Wesnoth

A minor unfairness in my recent text on Wesnoth was the use of an outdated version (1.12), instead of the latest (1.14).

I have since installed and briefly tried 1.14 through use of Debian’s “backports”. My experiments were cut short by the fact that it was unplayable on my computer for performance reasons. Specifically, the game used up an entire processor core even when doing nothing* and was slow as molasses—click somewhere and the reaction took place ten seconds later…**

*Including when being on the start screen and when having all animations deactivated.

**Note that this is a different type of delay than discussed in the original text: There we had artificial delays deliberately introduced by misguided developers; here we have delays as a side-effect of a too resource-consuming application.

If (as it likely was*) this performance delay was caused by changes to Wesnoth it self, it demonstrates a disastrous attitude so common in today’s software—the assumption that any type of performance waste in order to gain minimal benefits is acceptable. Notably, nothing that this game does should cause such performance delays. That the display part can be handled much more efficiently is proved by older versions of the game, the amount of calculation needed during user interaction is negligible, and the observed delays were by no means restricted to the AI’s/computer’s play**. And, no, neither 1.14 nor the older versions use graphics of an impressive kind—strictly 2D, a mostly static map (especially with animations off), no fanciful textures, …***

*It is unlikely-but-conceivable that some version incompatibilities or other problems in/with/between the simultaneously backported libraries and/or the original setup led to problems that are not the fault of Wesnoth. (The backports are typically nowhere near as thoroughly tested and come with far less guarantees than the “regular” Debian packages.)

**If it had been, it might be explained by deep analysis, simulation, or whatnot preceding the AI’s decisions. However, considering how trivial and fast the AI had been in older incarnations, this would have been a surprising development.

***Which is good: There is no true benefit to be found from such features in a game of this type. Equally, chess is played just as well with a simple wooden board and wooden pieces as if diamonds and rubies were used—likely, better.

I did manage some minor comparisons with 1.12 before giving up, however, and must amend my original criticism slightly: The blend-in of text and movement-to-and-from-a-war-council in 1.12 were not as slow as I perceived them when writing the original text. (However, both are still entirely unnecessary delays. Also note that at least the latter is sped up by a factor of four in my settings, compared to the default.) Here we likely see an effect of different standards of comparison: During regular play, I am used to things happening very quickly; coming straight from experiences with 1.14, I saw the contrast to the truly slow.

(As for differences, they appeared to be mostly optical. However, I did not manage to do any non-trivial game play nor test some of the features at all or more than very superficially, and there might have been significant changes that I am not aware of.)

Excursion on performance:
It is true that processing power is quite abundant today, with even a low-end cell-phone comparing well to the first computers that I knew. However, it is still not a limitless resource; not all computers have top-end processors (graphics cards, whatnot), notably because even an outdated low-end notebook can handle almost any task with ease;* and there are still factors like environmental impact and battery life to consider when a heavy workload increases energy consumption. In some case, even heat might be a factor to consider—what if a game is not playable on a hot summers day?

*For instance, my current notebook has a quadcore processor topping out at 2 GHz and only “on-board” graphics—and that is more than enough to watch even HD movies, play older versions of Wesnoth, listen to music, browse the Web, etc. Indeed, the average load on my processor is often below 1 %…

It is also noteworthy that some of this computing is a complete waste, e.g. because (as with 1.14) there is no benefit to it. Often, it is based on faulty assumptions about what the user wants.* Often, it is a pseudo-optimization; sometimes, it is even contra-productive.** It is particularly infuriating when an idle application (as with 1.14 above) runs the processor up—by rights, it should have a negligible processor load. Even as a professional software developer, I have problems understanding how they manage the opposite: Is it amateurish “busy waiting”? Is it a polling multiple times per second for an event that takes place every few hours? Is it a hidden malware that tries to spy on me? Is it an equally hidden bitcoin-mining operation? …

*For instance, many applications leave background processes hanging around after they are (ostensibly) terminated. This is usually with the intent that the application should start faster the second, third, fourth, … time around—but what if this does not happen for several weeks or only after a re-boot? Worse, there are some applications (especially on Windows machines) that insist on starting such background processes before the first application start. What if the actual application is then never started?

**A good potential example of contra-productive “optimization” is the “save_index” file of Wesnoth: Interacting with the saves is usually faster after deleting it… (I have not studied its exact purpose, but based on the name, it is likely intended to speed up said interaction. I note that I have never experienced any negative side-effects of the deletion.) And, no, this is not a unique example: I first deleted this file because I knew that emptying a cache (or a similar measure) often had led to a speed-up in other applications and thought that I should at least give it a try. Indeed, while caches can have major benefits in the right situation, they are often more a hindrance than a help. For instance, it only rarely makes sense for an application to add its own file caching on top of the file caching done by the operating system and other mechanisms. (And the introduction of SSDs have created many situations where the value of any file caching is strongly reduced compared to the past.)

Advertisement