Quote Originally Posted by ZorbaTHut View Post
Quote Originally Posted by ChickenArse View Post
To see what I'm talking about, get rammap from here: http://technet.microsoft.com/en-us/s.../ff700229.aspx
Well that's a convenient coincidence - just this morning I was wondering if a program that did this existed. Should've known it was in the sysinternals package.So . . . hmm. I suspect there's something a bit subtle going on here. Windows (like most modern operating systems) is quite lazy about clearing RAM. As it should be - empty RAM doesn't make the computer any faster, but if you keep around a bunch of stuff that might be useful in the future, well, it might be useful in the future.What I would guess is going on here is that, once Rift is closed, it happily drops all its memory mapped files . . . and Windows keeps them in RAM because hey why not, maybe you'll open Rift again soon. The real test here would be to open some other major memory-hungry game or application and see if those mapped files get booted out.It's vaguely possible that this isn't happening, but if so that would be a pretty huge Windows bug, and I strongly suspect they would have found it long ago if so.The important numbers to look at here are "Active", "Standby", and "Modified". Assuming I'm interpreting it right, "Modified" means "we absolutely need to keep this in memory because it may have been changed and otherwise we'll be throwing away information", "Active" means "a program is using this right now so we really really want to keep this in memory", and "Standby" means "eh, I guess we'll keep this in memory". As long as those memory-mapped files are in "standby" it's just the Windows optimizer doing its job and hoping you open Rift again so it can be opened really really fast this time.
Quote Originally Posted by ChickenArse View Post
The waste of address space causes the game to eventually invoke the rifterrorhandler and restart the game, at least on 32 bit systems.The crash takes longer if you stick to older zones (Idle in Sanctum instead of Tempest Bay for example)
This, on the other hand, is a problem we've been jousting with for quite a while. Rift uses a whole ton of memory for assets, and there's just no easy way around this. I don't think this is related to memory mapped files, I think it's just Rift being memory-hungry.I've got "look into memory usage" buried somewhere on my TODO list but it's a very long TODO list at this point.
Quote Originally Posted by Noshei View Post
So I'm guessing that the problem that I see (and I'm guessing others see as well) is that the system reports how much processing power rift is using across all of the cores and not just the ones that it is running on. This creates a bit of an illusion where it looks like rift is hardly using my process or, but it is really using as much as it can use.So am I on the right track here with why I don't really see rift using more than 30% of my processor at any point?
Yep, your guess is spot-on target. Very few programs are capable of actually using 100% CPU on modern computers. Multithreading is a bear, and saturating a high-end modern CPU is pretty much a pipe dream for modern games.I think we can do better than we're currently doing, and I've got some ideas on how to improve it, but I strongly doubt you'll ever see 100% without downgrading to a two-core computer.
Jump to post...