Hi Ahruman & other bug-squashers!
I have observed something which might be interesting for finding the culprit(s) of the Windows memory leak.
The slow-downs never happen in conjunction with the F6-maps with me. I tried it. I look in, get out, 50 times, in-flight, in the space station, nothing changes.
The crashes-to-desktop happen to 99% either when entering the main station or when exiting witchspace.
The imo most relevant observation: After a crash-to-desktop, there is something going on in the background which doesn`t affect the harddrive much (I can see the read/write on my keyboard, not much changes there) BUT everything is slower up to five minutes after playing Oolite - under Vista, a little looping blue ring appears, and that appears often after such a crash.
A few minutes later, gone. And if I wait for half an hour or so and play Oolite again, no crash, obviously less memory leak. For the same time as before.
And, obviously, the effect is stronger with more OXPs in and weaker with less in, but there anyways.
My hypothesis:
Could it be that a lot of variables are generated (for the core game & the oxps alike) which are then NOT ERASED from virtual memory? Reloaded again and again, stacking? Not even erased after the game ends, even if it ends in a regular, planned fashion?
Because, that would explain why oxps make a difference but don`t seem to be the culprits, why the system stays slow for a few minutes before it recovers (still upkeeping a Gig of unnescessary variables in virtual memory perhaps?) and why this happens usually when entering a station (NOT when exiting, mind!) and entering a system: Those are the moments when lots of variables are defined by the game, aren`t they
Think about it: The textures are there all the time, so they can`t be the reason - my game is not slow in-flight, and that with everything I have in!
A possible solution
Perhaps, seeing to it that unused variables and cache elements are properly deleted by the core game before going on to the next iteration? Automatic cache-flushing every now and then? And, obviously, an autosave at the witchpoint - at least a crashed game doesn`t have to restart at the beginning completely ...
Don`t know if this helps, but logically there might be something to that
Puzzling
L
Observations @memory leak Windows Vista with 1.70
Moderators: winston, another_commander, Getafix
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Observations @memory leak Windows Vista with 1.70
Yes. That’s what a leak is. :-)Lestradae wrote:My hypothesis:
Could it be that a lot of variables are generated (for the core game & the oxps alike) which are then NOT ERASED from virtual memory?
The memory is always freed up when an application exits, even if it crashed (unless Vista is a much worse operating system than I thought). However, Oolite’s memory-hogging behaviour causes other stuff to be paged to disk. Reloading this paged-out data is the cause of the slowness.Not even erased after the game ends, even if it ends in a regular, planned fashion?
The trick is to find the ones that are being leaked.Perhaps, seeing to it that unused variables and cache elements are properly deleted by the core game before going on to the next iteration?
The cache is flushed every time you dock, but this doesn’t decrease memory usage.Automatic cache-flushing every now and then?
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Cool… and it’s not like the fix is even there yet. :-) (The problem with unpredictable bugs is that they don’t happen predictably.)
E-mail: [email protected]