View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010051 | Dwarf Fortress | Technical -- General | public | 2016-10-26 12:45 | 2018-05-24 10:24 |
| Reporter | alexchandel | Assigned To | Loci | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| OS | OS X | OS Version | 10.12.0 | ||
| Product Version | 0.43.05 | ||||
| Summary | 0010051: DF still has 10% CPU Usage when paused with music & sound off. | ||||
| Description | When 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 Reproduce | 1. 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%. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
Tested with PRINT_MODE:SHADER, 7-8% CPU. |
|
|
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%. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
44.10 fresh install+default settings+loaded save takes around 2,2% cpu on win10-64 i7 2.0ghz while paused |
| 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 | |
| 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 |
