[MDX] Closing the application takes forever
Author
I'm making a simple terrain engine that is supposed to read new world sectors from cache files to be able to handle huge terrains. Works pretty neat but I haven't added any cache control to free unused memory so if I move the camera around the memory usage increases very rapidly :p
What surprises me is that closing the application takes FOREVER. I can see in the task manager that after i press the "X" on the window, the memory usage decreases with like 1mb/second and keeps doing that for about 60 seconds before it finally closes down. Why does this happen? Freeing memory shouldnt take too long, should it? The game uses lot's of indexed buffers to keep geomipmapping data. I realise that most of the time is probably spent freeing up that memory, but shouldnt it take more like 1 second than 120? :|
One possibility - are you leaking any D3D memory? I suppose that shouldn't be the case in a managed environment, but worth checking nonetheless.
If you leak lots of memory via native languages and have the debug runtimes enabled you'll get 10's of 1000's of lines of debug output. Simply writing that much data to the console really slows things down - I've had it take an extra 30-40 seconds to shutdown in these situations...
Failing that, maybe dig into the available .NET tools for debugging/profiling/monitoring? I'm not sure what they're called, but I've seen references to their existance [smile]
hth
Jack
If you leak lots of memory via native languages and have the debug runtimes enabled you'll get 10's of 1000's of lines of debug output. Simply writing that much data to the console really slows things down - I've had it take an extra 30-40 seconds to shutdown in these situations...
Failing that, maybe dig into the available .NET tools for debugging/profiling/monitoring? I'm not sure what they're called, but I've seen references to their existance [smile]
hth
Jack
That's very strange. I don't imagine it takes that long to allocate the data. How much data is being allocated? I'm thinking that even if it's a lot it seems it shouldn't take nearly so long to free all the memory. Mine takes about 3 seconds.
I'd be suspicious of a misplaced variable concatenation or some loop related delay. If you have some safe release of memory, then multiple attempts to release the same memory wouldn't show up.
It's one possibility. I guess their's tons of other possiblities though. (It might not necessarily be related to freeing memory.) Maybe post up any code related to cleanup.
(edit: oops - I posted same time as jollyjeffers)
I'd be suspicious of a misplaced variable concatenation or some loop related delay. If you have some safe release of memory, then multiple attempts to release the same memory wouldn't show up.
It's one possibility. I guess their's tons of other possiblities though. (It might not necessarily be related to freeing memory.) Maybe post up any code related to cleanup.
(edit: oops - I posted same time as jollyjeffers)
Author
I improved the performance by using a single indexbuffer per terrain patch and LoD-level. That should have decreased the number of indexbuffers with about 9 times. I could perhaps use a single indexbuffer for all LoD-levels on a patch but that would mean I have to generate all levels even if they aren't needed and that doesn't seem too good. Or maybe I just should keep one level of detail in the memory.
I also attempted to do some cache system to free terrain sectors that haven't been visited lately. I don't think it works though. I set alla references to null, but I see no difference in used memory. Is there any way to force a GC?
The performance is a lot better now but I still think it's too slow to shutdown. I have never had this problem with any game I've written in C++!
I also attempted to do some cache system to free terrain sectors that haven't been visited lately. I don't think it works though. I set alla references to null, but I see no difference in used memory. Is there any way to force a GC?
The performance is a lot better now but I still think it's too slow to shutdown. I have never had this problem with any game I've written in C++!
Quote:Works pretty neat but I haven't added any cache control to free unused memory so if I move the camera around the memory usage increases very rapidlyIt sounds very much like you are leaking memory with d3d resources (yes this can happen with managed dx). Make absolutely sure you are disposing all d3d resources when you close your app and if you absolutely need to create any d3d resources on a per-frame basis, make sure you are disposing them each frame too (or better yet, put them in a using).
If this is the case, I shudder to think what was happening to the memory you were leaking in your native dx apps [wink]
Regards,
ViLiO
A garbage collection can be forced by calling GC.Collect. It's generally not a good idea to do so. What would be better is to make sure any of your classes which contain DirectX resources implement the IDisposable interface. Then call dispose on them when you're done. You should look here: http://www.gotdotnet.com/team/libraries/whitepapers%5Cresourcemanagement%5Cresourcemanagement.aspx in section 3.4about implementing the dispose pattern. Don't forget to call Dispose on DirectX objects, too.
1 thing you might want to check depending on how your running the application:
There was this error / bug with vs 2005 dev edition where in some cases if I ran the application in debug mode through the vs interface it would take a fairly decent amount of time to load up and shut down.
But if I just ran the .exe of my application everything ran great.
If vs is your IDE and you test this, and this is the problem just let me know and I can try to find the Microsoft link on how to correct this problem, as I dont remember off the top of my head its been so long.
There was this error / bug with vs 2005 dev edition where in some cases if I ran the application in debug mode through the vs interface it would take a fairly decent amount of time to load up and shut down.
But if I just ran the .exe of my application everything ran great.
If vs is your IDE and you test this, and this is the problem just let me know and I can try to find the Microsoft link on how to correct this problem, as I dont remember off the top of my head its been so long.
I had the same problem with my program but managed to track it down to some variables not having their finalize or dispose methods called before the owner class closed down.
I just went through every variable instanced whether my own or directx owned and attempted to finalise or dispose of them. If that didn't work I set the variable to NULL. If that didn't work I assumed Microsft handled it fine.
Almost all of my classes are IDisposable so I can release memory when the object is finished with.
The program runs significantly better now.
I just went through every variable instanced whether my own or directx owned and attempted to finalise or dispose of them. If that didn't work I set the variable to NULL. If that didn't work I assumed Microsft handled it fine.
Almost all of my classes are IDisposable so I can release memory when the object is finished with.
The program runs significantly better now.
Chances are you're leaking D3D memory because of hooked events. What you're experiencing seems to be consistent with the behavior that Tom describes here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
