DirectX 9 mystical memory leak?

Started by
11 comments, last by ArdeII 20 years, 9 months ago
The unsafe word tells the runtime not to move those pointers around because they are being used.
Advertisement
That's BS. If task manager says the app is using 30megs - it is. That memory is allocated for that process and other processes cannot use it without paging that memory to disk.

I just got boned by this too. I was running some test with GraphEdit and I got the "start prayin' suckka, Windows is resizing your page file..." message. deveenv was using 257megs, and then my GraphEdit test went to allocate a number of large buffers. My computer started thrashing as loads of memory was paged out to disk and the swap file was made larger to accommodate it. After the test finished, devenv was still using 257megs. Minimizing it reduced the footprint to 2,584k, and restoring it brought it to 10,204k and now every time I click on something I have to wait for it to load again (like the macro recorder which pisses me off to the nth degree) and the memory consumption shoots back up (after starting the macro recorder and player it's back to 32meg - then my computer beat pud for a second while it collected and its back to 9megs).

devenv spends 95% of its time idle, and it did not release memory for another app to use it when I ran out of physical and virtual memory.

I'm rather impressed my machine has not locked-up.


[edited by - Magmai Kai Holmlor on July 10, 2003 6:58:39 PM]
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
The first .NET appliation to use particular things will have those things loaded and compiled into its processes memory space. This will inflate the size of your .NET applications in memory, but should stay well under 20 megs (besides whatever you allocate). You will see that if you run two instances of the program, once is substaintially smaller.

Do not worry about your small test application, it doesn''t allocate enough memory to bring about a garbage collection. I would recommend calling System.GC.Collect() ever few hundred frames or so if you are having problems with the garbage collector hanging your program for split seconds and effecting hte framerate. However if you keep the number of object allocations to a minium (note: allocate objects of pretty much any size you like without fear) you shouldn''t have much of a problem with the collector effecting your framerate. My engine chugs along doing nearly 100 low level collections every second or so. Its pretty increadable.

-SniperBoB-

This topic is closed to new replies.

Advertisement