Bay 12 Games Forum
Dwarf Fortress => DF Bug Reports => Topic started by: Nivim on June 04, 2009, 07:45:03 pm
-
I am not sure how much of a bug this is, or if it simply wasn't done. But Dwarf Fortress does not close cleanly, it slows down the computer afterwards and causes minor interference with other programs. I am guessing either Toady was too lazy to go through the trouble of programming a clean exit, or he is waiting for when the game is at version 1.0 so he wont have to mess with it too much.
-
What do you mean? I don't experience any problems with shutting down DF.
-
Are you using a non-Windows version? The Windows version works just fine for me, but maybe the Mac version leaves cruft lying around due to inexperience with that platform, say.
-
I'm on a Mac and I've not noticed any problems post-shutdown. To my knowledge, it shouldn't be possible to continue using resources after program exit unless you've made child processes and then not forced them to exit; Dwarf Fortress doesn't make child processes, so it can't leave effects behind after it's done.
Perhaps you're noticing a temporary slowdown as the memory Dwarf Fortress was using is freed and other programs start paging stuff in from the disk? How long does your slowdown last? And please tell us what operating system you're using and your computer specs.
-
It's the same effect most programs in existence have and goes away when you restart the computer. It isn't that much, around 5 fps hit for most things. A common problem, and it isn't specific to an operating system or computer setup (it's a Windows XP with run-of-the-mill decent processor and graphics card anyway). I was just pointing it out and to ensure that Toady would take care of it at some point.
-
I honestly have no idea what you speak of. I've started and closed DF hundreds of times while working on modded races and I have felt no ill effects- and my computer is slow enough that even the smallest decrease in efficiency would be instantly noticeable.
I was thinking you were referring to some sort of memory leak, but that would be resolved when the process ended (as I've made a huge memory leak before and it was gone by simply closing the program for good.)
Might it be a problem specifically with your computer or operating system?
-
Is it version 40d11?
I believe that one might be double-threaded now.
-
It's the same effect most programs in existence have and goes away when you restart the computer. It isn't that much, around 5 fps hit for most things. A common problem, and it isn't specific to an operating system or computer setup (it's a Windows XP with run-of-the-mill decent processor and graphics card anyway). I was just pointing it out and to ensure that Toady would take care of it at some point.
I also have no idea what you're talking about. And no offense but if you say "most programs" have this problem, you're wrong. This sounds like something wrong with your computer. Maybe you've got very low RAM, and you're actually seeing paging issues?
-
Not many programs churn through memory the way DF does. Lots of things consume lots of memory, but DF actually uses most of what it has fairly often. I wonder if its memory fragmentation... Not much else would cause nonspecific performance issues after a program quits. Except paging, and if it was that, I'm pretty sure you'd know :p
-
I am guessing either Toady was too lazy to go through the trouble of programming a clean exit, or he is waiting for when the game is at version 1.0 so he wont have to mess with it too much.
No.
Toady's exit code is fine.
There's a couple of reasons this could be:
If you did any memory editing and/or it crashes, it might not close cleanly.
Check for the process still running after exit.
Memory fragmentation - Free bits in the memory in non-sequential areas are taken by the same program.
Very similar to fragmentation of hard drives, but resolved by a simple restart, as RAM clears when it loses power.
If "most programs in existence" cause it, it's clearly not exclusive to DF, and it's clearly not a DF bug.
-
Is it version 40d11?
I believe that one might be double-threaded now.
All threads die on process exit. That's kind of the point of threads: to not go outside the process space.
-
if ur on windows theres a flag on the registry that u have to set otherwise windows wont unload the dlls the program required
hkey_local_machine->software->microsoft->windows->explorer, if it doesnt have a AlwaysUnloadDll key create it and set the standard value to 1
thats an old windows trick but most ppl never heard of it
-
if ur on windows theres a flag on the registry that u have to set otherwise windows wont unload the dlls the program required
hkey_local_machine->software->microsoft->windows->explorer, if it doesnt have a AlwaysUnloadDll key create it and set the standard value to 1
thats an old windows trick but most ppl never heard of it
That key is moot with Vista/7, as it automatically unloads unused DLLs.
Perfectly valid with XP or lower.
However, the number of DLLs that DF loads is not even close to capable of causing a 5 FPS drop in anything.
I see roughly 5MB of DLLs. If losing 5MB of RAM is causing a 5 FPS drop, I think you need more RAM.
-
if ur on windows theres a flag on the registry that u have to set otherwise windows wont unload the dlls the program required
Please spell out the words. "ur" just sounds clumsy in my head.
Anyway, DF is not and never will be double-threaded. I'm fairly certain Toady said this himself. I'm given to understand he would have to rework the program quite extensively for that to work. Even so, I am 100% positive that 40d11 isn't double threaded. So it's not even possible for it to be a problem with double-threading. My guess is just poor RAM. DF doesn't cause problems for me when closing, and I have RAM on my computer that is really in need of upgrading.
-
I wonder if its memory fragmentation...
I think I remember hearing somewhere else on this site about that,someone said that DF fragments horridly.
I have no experience with programming,I'm just telling you what I remember sounded bad.
-
Memory fragmentation is only really a problem within one process: if DF fragments its heap then it will use more memory than it strictly needs to but when you exit you will get all that back.
It is *almost* totally irrelevant whether the pages in physical ram are fragmented or not. Virtually nothing on a modern OS cares whether physical pages are contiguous.
-
That could explain why there are millions of page faults listed for DF when I look at task manager. I don't have any problems with exiting DF. There is a pause and a moment when Vista lists it as not responding (it's actually working fine, just busy and Vista thinks its not working. Just one of Vista's quirks) when it saves, but understandable since I'm playing on a large map. Exiting the game itself works as it should.
Maybe run defragmenter or something.
-
Fragmentation of a program's heap is not something you can do anything about, unless you modify the program itself (and even then it can be very difficult to solve). Memory fragmentation is nothing to do with disk fragmentation. I have no idea if DF really suffers from this or not, btw.
Having a very high page fault rate suggests that DF's working set (the amount of memory it's dealing with at one time) is larger than the amount of physical ram your OS can spare for it: i.e. you don't have enough memory available for it to run without paging. This isn't necessarily a bad thing - OSes are pretty smart about paging (even Windows) and the performance overhead of doing a bit of paging around the edges of the working set is not large. Windows' statistics on this are also a bit vague and fluffy and have a tendency to count things that are irrelevant as well as useful data, so take it with a grain of salt. If you were finding that DF ran slowly but your CPU (or one of them, anyway) was *not* maxed out, then you might look into this as a source of performance problems.
The thing where DF sometimes shows up as Not Responding in task manager or similar is because it's busy doing some operation which doesn't include sufficiently frequent peeking at the win32 message system. You're supposed to pay attention to win32 messages within a reasonably short time, but in practise all that happens if you don't is spurious notifications that the app is not responding, and missed repaints (e.g. cover up and then uncover the DF window during worldgen and notice how long it takes to actually get around to redrawing it).
The OP's problem is "DF's large working set size has pushed other applications' memory out to disk and probably forced the disk cache to be reduced in size, and now everything you touch causes lots of pageins, plus it takes some time for the disk cache to let itself grow to its original size again". :)
-
Fragmentation of a program's heap is not something you can do anything about, unless you modify the program itself (and even then it can be very difficult to solve). Memory fragmentation is nothing to do with disk fragmentation. I have no idea if DF really suffers from this or not, btw.
Having a very high page fault rate suggests that DF's working set (the amount of memory it's dealing with at one time) is larger than the amount of physical ram your OS can spare for it: i.e. you don't have enough memory available for it to run without paging. This isn't necessarily a bad thing - OSes are pretty smart about paging (even Windows) and the performance overhead of doing a bit of paging around the edges of the working set is not large. Windows' statistics on this are also a bit vague and fluffy and have a tendency to count things that are irrelevant as well as useful data, so take it with a grain of salt. If you were finding that DF ran slowly but your CPU (or one of them, anyway) was *not* maxed out, then you might look into this as a source of performance problems.
The thing where DF sometimes shows up as Not Responding in task manager or similar is because it's busy doing some operation which doesn't include sufficiently frequent peeking at the win32 message system. You're supposed to pay attention to win32 messages within a reasonably short time, but in practise all that happens if you don't is spurious notifications that the app is not responding, and missed repaints (e.g. cover up and then uncover the DF window during worldgen and notice how long it takes to actually get around to redrawing it).
The OP's problem is "DF's large working set size has pushed other applications' memory out to disk and probably forced the disk cache to be reduced in size, and now everything you touch causes lots of pageins, plus it takes some time for the disk cache to let itself grow to its original size again". :)
Actually, it's showing the not responding in the title bar, I don't need to look at task manager. I use task manager to 'crash' it when using the reveal utility since I don't want to actually have the tiles revealed when actually playing. I mainly use reveal to check the location of the magma pipe or whatever.
As for the worldgen window, when I'm genning large maps, it comes to a pause every several decades (it always stops at the same dates, such as 298) and acts like it's frozen and then after a minute or two, it resumes. When it's actually running, covering and uncovering it does not cause redrawing issues. When worldgenning a default world (medium worlds anyway), it doesn't have this problem
DF doesn't generally run slowly, although it will slow down to about 30-50 FPS when there is a high population, but that's just the FPS. When I pause, it jumps back up to around 100 FPS.
Actually, after playing for a long while, sometimes DF will suddendly slow down for no apparent reason as the FPS drops down to the 10s, 20s and does it even when paused. But a save, exit and reload fixes this.
How do I look at the win32 thing anyway? As for memory, I guess I could take a look and remove some stuff.
-
I think you misunderstood me, when I said "you're supposed to pay attention to win32 messages" I meant that application developers are supposed to code their applications to check the win32 message pump at a reasonable frequency - nothing to do with end users :)
There's a variety of reasons why FPS might temporarily drop, and they're unlikely to be anything to do with memory or windows resources, just the game's CPU usage.
-
Yea,I thought you were talking about end users when you said that about the win32 thing.
-
The OS could be precatching DF over other programs.
this means DF loads faster, and other programs don't load as fast as they could (using the precatching on those programs)
It should trigger most often for commonly used programs.
-
actually, df wont close for me period. (the "x" button wont work, but i can still use task manager.)
-
This thread is more than a year old and doesn't apply to the current version.
-
Hey I posted in this thread!
-
I know this is a massive necro post, but I can't help but answer a question I think I can help with. :-\
You say: (the "x" button wont work, but i can still use task manager.)
Well, Dwarf Fortress actually disables the x button - although you can still press it, rather than close it will bring up the menu instead.
To close it, you really should save the game, or abandon the fort to close properly from the start screen.
-
I know this is a massive necro post, but I can't help but answer a question I think I can help with. :-\
You say: (the "x" button wont work, but i can still use task manager.)
Well, Dwarf Fortress actually disables the x button - although you can still press it, rather than close it will bring up the menu instead.
To close it, you really should save the game, or abandon the fort to close properly from the start screen.
Or end the process with task manager if you want to cheat and close without saving.