Game slows down as I play it

[krugar]

Game Version: 3.1.2v2
System: Arch Linux running as a VMWare Guest. 1GB RAM. Dual Core 2.2GHz

Compilation flags:

--prefix=/usr \
--bindir=/usr/bin \
--sysconfdir=/usr/share/angband \
--with-configpath=/usr/share/angband \
--with-libpath=/usr/share/angband \
--enable-gtk \
--enable-sdl \
--enable-sdl-mixer

As I keep playing the game, I notice it starts to slow down considerably. This is only evident on repetition commands like digging or searching. The counter is very fast at the start of the game, but about half-an-hour into the game it starts taking 0,5 seconds per tick. As you can guess this has a huge impact on actions like digging.

These type of actions also take over one of my cores, which shoots over to 100%. I suspect this should be expected if the code doesn't take advantage of multi-processing. But the degradation of performance is more troublesome.

Does anyone else experience this? Have you found a solution? Do you suspect a cause?

Thank you.

[d_m]

I think this is a bug with the X11 mode (-mx11). If you play with curses (-mgcu) or SDL (-msdl) I am pretty sure it doesn't happen.

EDIT: I should say that right now the X11 mode doesn't really have a maintainer and is pretty long in the tooth.

[Magnate]

I think this is a bug with the X11 mode (-mx11). If you play with curses (-mgcu) or SDL (-msdl) I am pretty sure it doesn't happen.

EDIT: I should say that right now the X11 mode doesn't really have a maintainer and is pretty long in the tooth.

Isn't this the same bug as ticket #1142, which was fixed in r2009?? Strange that there would be another X11 resources bug ...

[PowerDiver]

Isn't this the same bug as ticket #1142, which was fixed in r2009?? Strange that there would be another X11 resources bug ...

He posted playing 3.1.2.v2. Is that before or after r2009?

[krugar]

I should say that right now the X11 mode doesn't really have a maintainer and is pretty long in the tooth.

How unfortunate
GTK mode is perfect for me, since it uses my .Xdefaults font settings and works very well with my working environment (a tilling wm). I confess I couldn't adapt at all to the sdl GUI. The curses option is the next best thing after GTK, I will have to give it a deeper look and see if I can replicate my current opened terminals.

But will have to rebuild. With the current GTK and SDL flags, cpu usage also is an issue with -ngcu. It's not if I build with those disabled (I know this because I actually started out with a ncurses only build before moving to GTK).

Isn't this the same bug as ticket #1142, which was fixed in r2009?? Strange that there would be another X11 resources bug ...

I took a look at that ticket. It apparently seems it's back. With these nuances...

- It uses up full CPU resources on initial screen.
- When playing it uses full cpu resources when counters are ticking.
- Performance degrades over time.
- Built with X11 and GTK disabled solves all cpu and degradation issues.

[AnonymousHero]

The "degrades over time" bit makes me think that it isn't necessarily related to ticket #1142. The problem in that bug only really applies when the WM is trying to resize the window.

[Magnate]

I took a look at that ticket. It apparently seems it's back. With these nuances...

- It uses up full CPU resources on initial screen.
- When playing it uses full cpu resources when counters are ticking.
- Performance degrades over time.
- Built with X11 and GTK disabled solves all cpu and degradation issues.

Just to be absolutely clear: are you reporting this about the latest nightly (or a personal build from trunk), or 3.1.2v2?

[krugar]

Just to be absolutely clear: are you reporting this about the latest nightly (or a personal build from trunk), or 3.1.2v2?

It's for 3.1.2v2, Magnate. See initial post.
But I have not reported the bug yet. I was hoping for a confirmation on this thread from someone else experiencing this problem in order to do that.

I'm confident this isn't an isolated case. But the fact no one has yet confirmed it, is troubling me. I'm surprised that few, in anyone, plays the game in GTK mode.

[AnonymousHero]

From the screenshots you posted in your other thread you seem to be using a WM which will want to resize windows "arbitrarily". It may well be that the fix for ticket#1142 wasn't aggressive enough; it still tries to force a minimum size of 80x24 for each terminal.

Does the game consume 100% CPU just after you've started it (and perhaps moved the windows into the appropriate configuration)?

[krugar]

It may well be that the fix for ticket#1142 wasn't aggressive enough; it still tries to force a minimum size of 80x24 for each terminal.

The game does behave differently than the typical GTK application when I try to resize individual windows. They don't obey as naturally as others do. I guess, because the window geometry is indeed focused on a predefined value that it wants to fix for me.

For dynamic tilling WMs, it's actually desirable that the software doesn't try to impose a window geometry while at the same time offering the possibility to change it. This is especially true of software that opens more than one window. Consider this:

Because we may dynamically alter the geometry of other windows when doing a change on a single window, if the software does that, we find it neigh impossible to properly adjust the environment to our liking. It also (this is the good part) tends to expose a few bugs on the tilling WM code

What we prefer is for software to flow (wrap) content freely inside the window as we resize it. It's our task to ensure the text displays as intended. We expect to achieve that by giving the window sensible dimensions. Not by having the software fix the dimension for us. In other words, it's the user task to guarantee data displays properly, not the software's. The latter only wants to manage the flow of text. It doesn't care if it just wrapped part of that pretty table and its now a mess

Does the game consume 100% CPU just after you've started it (and perhaps moved the windows into the appropriate configuration)?

Right after I start it, while still on the initial screen where it waits for me to load an existing game or start a new one. It goes back to normal CPU usage when I do one of those.

It then only consumes the CPU when I perform looping actions like digging or searching. They also start to perform slower and slower, the longer I stay in the game. It's not tied to the number of opened game windows.

[Magnate]

The game does behave differently than the typical GTK application when I try to resize individual windows. They don't obey as naturally as others do. I guess, because the window geometry is indeed focused on a predefined value that it wants to fix for me.

For dynamic tilling WMs, it's actually desirable that the software doesn't try to impose a window geometry while at the same time offering the possibility to change it. This is especially true of software that opens more than one window. Consider this:

Because we may dynamically alter the geometry of other windows when doing a change on a single window, if the software does that, we find it neigh impossible to properly adjust the environment to our liking. It also (this is the good part) tends to expose a few bugs on the tilling WM code

What we prefer is for software to flow (wrap) content freely inside the window as we resize it. It's our task to ensure the text displays as intended. We expect to achieve that by giving the window sensible dimensions. Not by having the software fix the dimension for us. In other words, it's the user task to guarantee data displays properly, not the software's. The latter only wants to manage the flow of text. It doesn't care if it just wrapped part of that pretty table and its now a mess



Right after I start it, while still on the initial screen where it waits for me to load an existing game or start a new one. It goes back to normal CPU usage when I do one of those.

It then only consumes the CPU when I perform looping actions like digging or searching. They also start to perform slower and slower, the longer I stay in the game. It's not tied to the number of opened game windows.

But until you confirm that this bug exists in the latest nightly, we cannot be certain that the fix for #1142 did not solve the problem!

[krugar]

But until you confirm that this bug exists in the latest nightly, we cannot be certain that the fix for #1142 did not solve the problem!

Magnate, I'm using 3.1.2v2 compiled from sources. I thought that was the latest build.

Anyways, this is Saturday and I finally have time to dedicate. I checked out the latest code from svn://rephial.org/angband/trunk (I believe this is what you meant, since "nightly builds" are currently simply a build script that compiles only for Windows and OSX), generated the config file and built with the following flags:

--prefix=/usr \
--bindir=/usr/bin \
--sysconfdir=/usr/share/angband \
--with-configpath=/usr/share/angband \
--with-libpath=/usr/share/angband \
--disable-x11 \
--enable-gtk \
--disable-sdl \
--disable-sdl-mixer

I execute with the following commands:

angband
angband -mgtk
angband -mgtk -- -n5
angband -mgcu -a

What happens:

1. First three options result in high CPU consumption during initial screen and during normal gameplay. Once I leave the initial screen by creating a new character or loading an existing one, CPU returns to normal. But it's evident the game utilizes abnormal resources when performing repetitive actions, such as:
- Digging
- Searching
- Using the . (dot) command
These use large amounts of CPU resources.

2. First three options also result in degradation of performance over time. Now, since I'm running Linux as a virtual machine guest (vmware), I'm not inclined yet to attribute this particular degradation issue to angband. I'd have to investigate that deeper. But being a linux newb, I'm still not comfortable with linux debugging/reporting tools, and their usage, to be effective at this type of analysis on this platform.

3. The last option works normally and as expected without abnormal CPU consumption. Meaning, this is definitely to do with the GTK interface.

4. Totally unrelated (or not?), but third option does not open 5 windows as I requested. It only opens the main window.

edit:
btw, if 3.1.2v2 is indeed not the latest build from trunk, it would really help if you guys added a build number in trunk to defines.h. It's a tad bit confusing otherwise, because after building from the repository the initial screen still displays 3.1.2

[Magnate]

Magnate, I'm using 3.1.2v2 compiled from sources. I thought that was the latest build.

No. As you discovered, the latest build is whatever's in trunk - currently r2041. 3.1.2v2 is based on r1950 or thereabouts.

What happens:

1. First three options result in high CPU consumption during initial screen and during normal gameplay. Once I leave the initial screen by creating a new character or loading an existing one, CPU returns to normal. But it's evident the game utilizes abnormal resources when performing repetitive actions, such as:
- Digging
- Searching
- Using the . (dot) command
These use large amounts of CPU resources.

2. First three options also result in degradation of performance over time. Now, since I'm running Linux as a virtual machine guest (vmware), I'm not inclined yet to attribute this particular degradation issue to angband. I'd have to investigate that deeper. But being a linux newb, I'm still not comfortable with linux debugging/reporting tools, and their usage, to be effective at this type of analysis on this platform.

3. The last option works normally and as expected without abnormal CPU consumption. Meaning, this is definitely to do with the GTK interface.

4. Totally unrelated (or not?), but third option does not open 5 windows as I requested. It only opens the main window.

edit:
btw, if 3.1.2v2 is indeed not the latest build from trunk, it would really help if you guys added a build number in trunk to defines.h. It's a tad bit confusing otherwise, because after building from the repository the initial screen still displays 3.1.2

Yes - there was a ticket for this - ah yes, it's #1012 and it's still outstanding. Thanks for the nudge - will try and fix this.

So, it does look like you have found a related but different CPU consumption bug. I suspect it is not specific to Gtk and will also happen with -mx11, but this needs testing.

Thanks for your continued tests. Before I open another ticket, I'd be grateful if you could replicate your tests in a non-vmware environment, i.e. native Linux (both -mgtk and -mx11). If that's not possible let me know and I'll try to do it myself (I don't have vmware so it will at best be a partial match).

[krugar]

So, it does look like you have found a related but different CPU consumption bug. I suspect it is not specific to Gtk and will also happen with -mx11, but this needs testing.

I did a preliminary test with the following compilation flags:

--enable-x11 --enable-gtk --disable-sdl --disable-sdl-mixer

Results are as follows:

angband -mgcu  : OK
angband -mx11  : OK
angband -mgtk  : FAIL

I also tested with Openbox (a stackable WM) with same results.

Note: You can ignore reported behavior 4 on my post above. It only happens when compiling for GTK with --disable-x11. Meaning, I was being dumb

Before I open another ticket, I'd be grateful if you could replicate your tests in a non-vmware environment, i.e. native Linux (both -mgtk and -mx11). If that's not possible let me know and I'll try to do it myself (I don't have vmware so it will at best be a partial match).

Unfortunately I currently don't have the means to do a native installation of Linux. Very short on disk space to allocate a new partition. I wouldn't worry much with the degradation bit. I'm pretty sure it's related to the bug in the GTK interface, wherever it is.

[Magnate]

I did a preliminary test with the following compilation flags:

--enable-x11 --enable-gtk --disable-sdl --disable-sdl-mixer

Results are as follows:

angband -mgcu  : OK
angband -mx11  : OK
angband -mgtk  : FAIL

Ah, this is excellent news - this means it's purely a gtk bug and is entirely unrelated to #1142. Opened as #1192 - but don't hold your breath, as the dev team currently lacks a gtk expert.