View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009637 | Dwarf Fortress | Adventure Mode -- General | public | 2016-03-18 09:56 | 2016-07-28 19:11 |
| Reporter | Ogg the Blinky Sock | Assigned To | lethosor | ||
| Priority | high | Severity | major | Reproducibility | have not tried |
| Status | resolved | Resolution | duplicate | ||
| Platform | Apple iMac (27-inch, Late 2012) | OS | Apple OS X Yosemite | OS Version | 10.10.5 |
| Product Version | 0.42.06 | ||||
| Summary | 0009637: assault on goblin city abruptly plagued by minutes-long processing time per turn | ||||
| Description | I was in the midst of heroically assaulting the Dark Fortress of Curseplan, methodically eliminating all hostile goblins, and was working my way through it underground near the centre of the city. I came to a stairwell that was only modestly unusual in extending four flights or so with antechambers on each level. The game suddenly and abruptly began to take over a minute between movement turns. I recently quadrupled the RAM on my computer to 32 GB, which had previously sped up movement a great deal. However, the program is currently only requiring 2.55 GB of memory, with at least half the available memory unused, so I don't think that a physical limit is the problem. Priority is set to "REALTIME" in init.txt, but "ps -l" reports the 'nice' value as zero and the absolute/actual priority as 97. These values however are confirmed to exist since the program launches. | ||||
| Additional Information | Save file is at http://dffd.bay12games.com/file.php?id=11867 | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0007526 | confirmed | Dark towers contain thousands of goblins and trolls, causing lag |
|
|
Possibly related to issue 0000136, which seems to be essentially that DF is a 32 bit game and cannot directly address much more than 2 GB of memory. |
|
|
Actually, the above won't affect OS X 32 bit binaries, even less so these days. The program should have access to the full 4 GB addressable space. Poking around with system diagnostic tools shows that about 19.5 s of a 20 s system call sample was taken up by 'pthread_cond_timedwait' state, which seems to be associated with a call stack of "mach_wait_until > SDL_Delay > SDL_Linked_Version > SDL_SemWait > _pthread_body > _pthread_start > thread_start". There seem to be an inordinate number of sephamores and blocks involved, to my 99% uneducated eye. Any debugging information that I can figure out how to provide, and which would be useful, I would be happy to provide. |
|
|
It might have just loaded an antechamber full of goblins/trolls/etc - goblin fortresses can have _thousands_ of them. |
|
|
I believe this is known already. |
|
|
Just noticed: this is a duplicate of 0007526. |
|
|
I reviewed 0007526 and it seems more likely than not that this is the same issue, although I don't know what the save-file actually holds. It should probably be closed as a duplicate and noted with a save file link in that report. |
|
|
Thanks for investigating - I'll merge this into 0007526. A couple notes: - The process priority setting only affects anything on Windows - I'm willing to bet that all the "pthread_cond_timedwait" things you were seeing were just on one thread, probably some SDL event loop-related thread, that was waiting for DF to finish calculating things |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-03-18 09:56 | Ogg the Blinky Sock | New Issue | |
| 2016-03-21 15:02 | Ogg the Blinky Sock | Note Added: 0034893 | |
| 2016-03-21 15:03 | Ogg the Blinky Sock | Note Edited: 0034893 | |
| 2016-03-21 15:03 | Ogg the Blinky Sock | Note Edited: 0034893 | |
| 2016-03-21 21:22 | Ogg the Blinky Sock | Note Added: 0034894 | |
| 2016-04-01 01:43 | jjl2357 | Note Added: 0034950 | |
| 2016-04-26 15:02 | untrustedlife | Note Added: 0035049 | |
| 2016-07-27 16:17 | InfantIguana | Note Added: 0035709 | |
| 2016-07-28 16:42 | Ogg the Blinky Sock | Note Added: 0035719 | |
| 2016-07-28 19:11 | lethosor | Note Added: 0035721 | |
| 2016-07-28 19:11 | lethosor | Relationship added | duplicate of 0007526 |
| 2016-07-28 19:11 | lethosor | Status | new => resolved |
| 2016-07-28 19:11 | lethosor | Resolution | open => duplicate |
| 2016-07-28 19:11 | lethosor | Assigned To | => lethosor |
