Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010051Dwarf FortressTechnical -- Generalpublic2016-10-26 12:452018-05-24 10:24
Reporteralexchandel 
Assigned ToLoci 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS XOS Version10.12.0
Product Version0.43.05 
Target VersionFixed in Version 
Summary0010051: DF still has 10% CPU Usage when paused with music & sound off.
DescriptionWhen paused, with no sound running, there should be nothing for DF to do but render a static, unchanging window, which other program manage to do with 0.0% CPU usage. However, in PRINT_MODE:STANDARD, DF constantly uses 9-10% CPU.

Don't get me wrong, 10% idle CPU isn't the end of the world (at least it's not 57%, like with PRINT_MODE:2D). But it's a significant drain on laptop batteries, and it makes playing dwarf fortress on airplane flights or long car rides difficult.

It should be feasible to run DF with near 0% CPU usage, especially when paused/idle.

(If there is a known 0% idle "low-battery" configuration, I couldn't find it documented anywhere in the wiki or the manual)
Steps To Reproduce1. Set PRINT_MODE:STANDARD, SOUND:NO, VOLUME:0, SINGLE_BUFFER:NO
2. Start Dwarf Fortress
3. Load a paused world.
4. Look at % CPU of dwarfort.exe in activity monitor

It should be 0%, but it's 9-10%.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-10-26 12:45alexchandelNew Issue
2016-10-26 12:57alexchandelNote Added: 0036001
2016-10-26 13:33alexchandelNote Added: 0036002
2016-10-26 13:55alexchandelNote Added: 0036005
2016-11-25 07:06QuietustNote Added: 0036065
2017-04-25 22:31alexchandelNote Added: 0036468
2017-04-26 02:13PatrikLundellNote Added: 0036469
2017-04-26 03:07LociStatusnew => assigned
2017-04-26 03:07LociAssigned To => Loci
2017-04-26 03:07LociNote Added: 0036470
2017-05-12 10:32alexchandelNote Added: 0036527
2017-05-12 10:34alexchandelNote Edited: 0036527bug_revision_view_page.php?bugnote_id=0036527#r14733
2017-05-17 14:17lethosorNote Added: 0036536
2018-05-24 10:24risusinfNote Added: 0038375
2018-05-24 10:25risusinfNote Edited: 0038375bug_revision_view_page.php?bugnote_id=0038375#r15599

Notes
(0036001)
alexchandel   
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   
2016-10-26 13:33   
Tested with PRINT_MODE:SHADER, 7-8% CPU.
(0036005)
alexchandel   
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   
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   
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   
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   
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   
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   
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   
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