0010051: DF still has 10% CPU Usage when paused with music & sound off.

Notes
(0036001) alexchandel (reporter) 2016-10-26 12:57	I tested with PRINT_MODE:VBO, and paused CPU usage is down to 6-7%. But it's still taking a non-zero amount of CPU to change nothing, play no sound, and block waiting for user input.

(0036002) alexchandel (reporter) 2016-10-26 13:33	Tested with PRINT_MODE:SHADER, 7-8% CPU.

(0036005) alexchandel (reporter) 2016-10-26 13:55	Ok, even PRINT_MODE:TEXT uses 8-9% CPU when paused with no sound. Now I'm stumped. This should not use more than 0.1%.

(0036065) Quietust (reporter) 2016-11-25 07:06	The complexity of your fortress is a very big factor - a small fresh embark might only use 0-1% CPU, but a large embark with multiple megaprojects can easily consume much more because the game completely redraws the screen every single frame (which involves a lot of lookups for a complex landscape with lots of units, buildings, constructions, etc.) even if nothing has technically changed. You might have better luck if you turn down the G_FPS_CAP setting from its default of 50. Dwarf Fortress isn't anywhere close to being done and no significant amount of optimization has been done on it, so it's not surprising that it's inefficient.

(0036468) alexchandel (reporter) 2017-04-25 22:31	So when the game is paused, and no inputs are coming in, and no timers are activating, it still performs all the lookups every single frame? Why doesn't it just use the data for the last frame? That should be an easy optimization. And combined with PRINT_MODE:TEXT and no sound, that should ensure <0.1% CPU is used when the game is paused, since it doesn't even need to update the screen.

(0036469) PatrikLundell (reporter) 2017-04-26 02:13	The simplest way to implement rendering is to do it the same way every time, rather than implement several modes that have to be maintained and tested every time DF is updated. When you try to get smart about it you'll risk introducing bugs where things fail to be rendered because the "pause" renderer wasn't notified. This is particularly true when using DFHack, which relies on the fact that changes to data structures are picked up and rendered as they are performed. It's not impossible, and probably not even hard, to optimize these things, but it's an issue for a rather small section of the user base that Toady would spend time on rather than e.g. fix the crash bug when weapon trap components fail, or a bazillion of other rather serious bugs (not to mention optimization that would improve FPS for more users). And, as said, it would also make life hard for DFHack scripts.

(0036470) Loci (manager) 2017-04-26 03:07	When the game is paused the player can still move the viewport and some tiles cycle to display additional information. If you want to minimize processor usage (when pausing for extended periods or switching to another program) you can bring up the options menu using 'ESC' to prevent the viewport from being constantly reprocessed/redrawn. To reduce the amount of work required during the redraw you can embark at a treeless site (0008877) and try other FPS-saving suggestions ( http://dwarffortresswiki.org/index.php/DF2014:Maximizing_framerate [^] ). Dwarf Fortress is still in early alpha; minor optimizations are a long way off.

(0036527) alexchandel (reporter) 2017-05-12 10:32 edited on: 2017-05-12 10:34	This isn't in game, although staying on the ESC menu slightly reduces CPU usage. This is on the first menu/load screen (the one with the "Continue Playing" and "Create New World!" options). With PRINT_MODE:FRAME_BUFFER and SOUND:NO, the game sits at 6-6.5% CPU.

(0036536) lethosor (manager) 2017-05-17 14:17	Like Loci said, this is a very minor optimization. DF isn't "doing nothing" even when you turn off sound - it's polling for input events frequently, and renders the current screen several times per second. This is because some screens do need to display updates without user input, and it's much simpler to handle that by rendering the current screen frequently regardless of what screen it is. Also, DF already avoids redrawing tiles that haven't changed since the last frame, so it's not like it's drawing the entire screen after every frame. Sure, DF could potentially cache some screen data, but that would be extra work for Toady and would be more of a suggestion. If you haven't yet, I highly recommend decreasing your G_FPS_CAP (and possibly FPS_CAP) settings. I've been able to remedy CPU usage that I deemed "too high" by decreasing G_FPS_CAP to around 24. PatrikLundell: I'm not sure what you're talking about - DFHack would still be entirely able to change data in DF even if it wasn't rendered immediately.

(0038375) risusinf (reporter) 2018-05-24 10:24 edited on: 2018-05-24 10:25	44.10 fresh install+default settings+loaded save takes around 2,2% cpu on win10-64 i7 2.0ghz while paused

Issue History
Date Modified	Username	Field	Change
2016-10-26 12:45	alexchandel	New Issue
2016-10-26 12:57	alexchandel	Note Added: 0036001
2016-10-26 13:33	alexchandel	Note Added: 0036002
2016-10-26 13:55	alexchandel	Note Added: 0036005
2016-11-25 07:06	Quietust	Note Added: 0036065
2017-04-25 22:31	alexchandel	Note Added: 0036468
2017-04-26 02:13	PatrikLundell	Note Added: 0036469
2017-04-26 03:07	Loci	Status	new => assigned
2017-04-26 03:07	Loci	Assigned To	=> Loci
2017-04-26 03:07	Loci	Note Added: 0036470
2017-05-12 10:32	alexchandel	Note Added: 0036527
2017-05-12 10:34	alexchandel	Note Edited: 0036527	View Revisions
2017-05-17 14:17	lethosor	Note Added: 0036536
2018-05-24 10:24	risusinf	Note Added: 0038375
2018-05-24 10:25	risusinf	Note Edited: 0038375	View Revisions

Relationships