consumes too much CPU when it should be idle

[darkgod]

What the hell is a page fault ?

[greycat]

I believe a page fault is when a program is only partially loaded into memory, and the OS receives a request for a chunk of memory that's not currently resident in physical RAM. Then it has to be swapped (paged) in. Or something like that.

[greycat]

Ahh that's good old mesa, it's not using your video driver opengl.

According to http://wiki.debian.org/AtiHowTo and glxinfo, I have "direct rendering" and that's apparently a good thing. But I don't understand all this stuff.

Try disabling the map display: Comment out lines 430 and 431 in game/modules/tome/class/Game.lua

See if this is faster, much faster, terribly faster, ...

My experiments here are extremely non-scientific. I have other processes running and I did not stop them. I was only looking for overall trends, not hard data. Without t-engine running at all, CPU use was ~10%.

I started a new character (last one was dead) and ran normally for a bit, letting it sit idle in the Noobshaws while I let vmstat 10 run. Overall it seems to use about 50-60% of CPU (user+system).

Then I saved, made the change you suggested, and restarted. I had somehow read it as "minimap", so I was a bit surprised that the entire MAIN map was gone (black). Obviously I couldn't play at all in that state, but I let it sit for a bit.

There wasn't any real difference in the CPU use -- still about 50-60% overall, dropping to ~10% when I saved again.

You can also try to change the zdepth at line 31 of game/engines/default/engine/Map.lua
Set it to 1 and see if it is faster.
(This will bork display terribly, you probably will only see the ground and just partially)

Again, about 50% CPU use overall during the brief time I let it sit.

Whatever's eating up the CPU, it doesn't appear to be the main map display. (I suspect something polling for keyboard/mouse events in a tight loop, but that's just a wild-ass guess.)

[Zop]

greycat said it as much as I know it is. A common idea is that a pagefile is to increase the available memory, but when a program tries to use the memory that's actually hard disk space, it's a hell of a lot slower. Now that we have gallons of RAM, the pagefile is more used to store things that probably won't be accessed again, or at least any time soon.

Page faults of this quantity seems like te4 and the OS are fighting. I found if I move the mouse constantly, the page fault rate decreases 40%

I tried making a RAM disk and assigning the pagefile to that disk, and the only stuttering I've seen so far is during saving or sometimes when casting a spell with a graphic animation.

[darkgod]

Hum

Can you try recompiling the game while adding this line just before the switch on line 670 of src/main.c:

Code: Select all

			printf("handling sdl event %d\n", event.type);

You should see lots of event type 24 while iddling (this is the redraw, about 33 per seconds) but not much else.

Also try disabling other parts of the Game:display() method and see if one of those makes things run faster.
You can also try emptying completly the display() method and see if it is faster.

As for the page faults this eludes me completly why it would do that. I do not do ay fancy stuff, maybe it's luajit ? I'll try to provide you with a non-luajit windows binary tonight when I get back home.

You can also try compiling it without luajit greycat

Thanks

[darkgod]

http://te4.org/dl/tmp/t-engine-beta10-noluajit.exe

Please windows people try this one, see how it fares

[darkgod]

Whoopos bad version uploaded, try now

[darkgod]

Edit: Ok, just to confirm my impressions, I started a new archer character. After playing a couple of shadowblades for a total of about 4 hours with almost no lag, the archer got very bad lag after just 5 minutes of crazy shooting to a bunch of worm masses and other nasty critters. IMO targeting system (at least, archer's one) contains some serious performance issue.

Ok can you please try to replace the tick() method in game/engines/default/engine/GameEnergyBased.lua
with this one:

Code: Select all

function _M:tick()
	engine.Game.tick(self)

	-- Give some energy to entities
	if self.level then
		local i, e
		local arr = self.level.e_array
		for i = 1, #arr do
			e = arr[i]
			if e and e.act and e.energy then
--				print("<ENERGY", e.name, e.uid, "::", e.energy.value, self.paused, "::", e.player)
				if e.energy.value < self.energy_to_act then
					e.energy.value = (e.energy.value or 0) + self.energy_per_tick * (e.energy.mod or 1)
				end
				if e.energy.value >= self.energy_to_act then
					e.energy.used = false
					e:act(self)
				end
--				print(">ENERGY", e.name, e.uid, "::", e.energy.value, self.paused, "::", e.player)
			end
		end
	end

	local nb = 0
	local arr = self.entities
	for i, e in pairs(arr) do
		e = arr[i] nb = nb + 1
		if e and e.act and e.energy then
			if e.energy.value < self.energy_to_act then
				e.energy.value = (e.energy.value or 0) + self.energy_per_tick * (e.energy.mod or 1)
			end
			if e.energy.value >= self.energy_to_act then
				e.energy.used = false
				e:act(self)
			end
		end
	end
	print("====", nb)

	self.turn = self.turn + 1
	self:onTurn()

	-- Try to join threads if any, every hundred turns
	if self.turn % 100 == 0 then
		self:joinThreads(0)
	end
end

Then post a log of the slowdown please

[Feanor.81]

Here it is, I guess all that zeros mean that the problem is not in the tick() method.

I attached a screenshot taken during a slowdown, too, showing that t-engine process is using >70% CPU while my character is just sitting there.

Further note: Got slowdown with a ShadowBlade too, after about 20 minutes of play in the Trollshaws. Could it be related to the specific zone? I'll move my archer to Amon Sul tomorrow, and see if gets any better.

[darkgod]

Hum damnit :/
I'll try to cook up some code to test the time individual parts of display are using.

[Feanor.81]

Some information that could be useful to tackle the problem: I just found out that, minimizing all windows (including ToME one) brings back the t-engine process CPU usage to a nice 20%; restoring ANY window (even leaving ToME minimized) takes back the usage to 60-70%. This is a strange behavior indeed, and could subtend a bad usage of OS resources (by LUA engine itself or one of the external libraries used for rendering, playing audio, etc.).

As a side note, t-engine process thread count is constantly 13, so the thread pooling is working just fine.

[All observations done with the nojit executable, anyways I didn't notice any change switching between the two].

BIG UPDATE: Found a workaround to prevent the slowdown issue, by starting t-engine process with "Disable visual themes", "Disable desktop composition" and "Disable display scaling on high DPI settings" compatibility options enabled (but I think only the second matters, I will be trying enabling again the other two). This way I've been able to play my archer for 15 minutes without any slowdown, and CPU usage never went higher then 30%. This makes me think that probably there is some graphic compatibility issue with Win7 Aero theme, since:

Code: Select all

Disable desktop composition: This will disable the advanced features in the Aero Glass interface, such as transparency. This is a good choice if you notice problems with windows not being drawn correctly. For example, if the IDE includes visual tools to create and edit forms or dialogs, you may find that controls are drawn very slowly or aren't redrawn in the correct position. Disabling this feature will often correct the problem, however it will force the entire desktop (not just the application) to disable the Aero UI until the program terminates.

Now, it's not really a problem disabling Aero while playing, it would suffice just adding an entry in release notes to suggest Win7 users turning on this option if experiencing graphic issues.

[darkgod]

Please try to replace the display() method in game/modules/tome/class/Game.lua with this one: http://pastebin.com/SPAYHB6G

Then post here the output when it runs fine and when it runs slow please.

[Feanor.81]

With "when it runs fine", do you mean w/ desktop composition disabled (no more slowdown) or w/ desktop composition enabled (this will cause slowdown) before the actual slowdown takes place?

[darkgod]

Uh ?
You mean in some conditions it never slows down ?

Anyway do it in the same environment you did for the last tests

[greycat]

Hum

Can you try recompiling the game while adding this line just before the switch on line 670 of src/main.c:

Code: Select all

			printf("handling sdl event %d\n", event.type);

You should see lots of event type 24 while iddling (this is the redraw, about 33 per seconds) but not much else.

Did this, started a dwarf fighter, played for about 2 minutes, saved-and-exited.

Code: Select all

griffon:/usr/local/src/t-engine4-src-1.0.0beta10b$ grep 'handling sdl even' logs/Urist | sort | uniq -c
      1 handling sdl event 17
     87 handling sdl event 2
   2086 handling sdl event 24
     86 handling sdl event 3
    383 handling sdl event 4
      3 handling sdl event 5
      3 handling sdl event 6

If the game is really calling an SDL routine dozens of times every second, even when it's just sitting idle, that might also account for the CPU use....

You can also try compiling it without luajit greycat

Thanks

[/quote]

I'd have to figure out what that means first.... "premake4 --help" says there's a --lua=VM_Type option, and its choices are "default" or "jitx86". I've been typing "premake4 gmake" and then "gmake" to compile, so I'm apparently using the "Default Lua Virtual Machine", whatever that means.