Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010051Dwarf FortressTechnical -- Generalpublic2016-10-26 12:452018-05-24 10:24
Assigned ToLoci 
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)
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%.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
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.
alexchandel (reporter)
2016-10-26 13:33

Tested with PRINT_MODE:SHADER, 7-8% CPU.
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%.
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.
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.
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.
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 ( [^] ).

Dwarf Fortress is still in early alpha; minor optimizations are a long way off.
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.

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.
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

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker