I am curious. What files hog memory even after they are removed from a scene? I know the best practice is to save your scene as a .pz3 then exit/re-start Poser before a render... but I am curious what if any data is "persistant" in Poser memory usage even if you have remove it from a scene.

A rope...lol..sorry bad joke:) I think it's how our computer works it seems to hold on to our memory...I use a memory manager to replace the memory back..Maybe somebody could explain it better...

I use a memory manager too, but when it comes to Poser, it doesn't seem to make a difference.

Screens seem to be the worst thing that poser stores in the memory even when you stop using them.

What are screens? And how do you not use them?

I meant textures, ie jpgs and bmp files etc.

The P6 manual says the texture list retained in Material Room is only a list of recently used and does not reflect texture in memory?

I wasnt talking about poser 6, it might have been changed there, if it has then there really shouldnt be anything kept in the memory in poser 6 (just to make that clearer).

There may be less memory available to your OS than there should be because of memory fragmentation. Some programs - and I believe Poser is a prime culprit - don't free up unused memory properly, or at least, leave non contigious chunks of RAM dotted around. Early versions of Corel Draw (which I hate with a passion) were notorious for this, too.

Coppula eam se non posit acceptera jocularum.

My Store

My Gallery

I think worse than RAM, memory in your swap file is abused by Poser. I posted a couple of days ago with comments sent to me by an e-Frontier employee somewhat discussing this. What I have done since then is a full defrag of my hard disk, then I set my swap file to an exact size. Unfortunately I have an older drive, and the access time is a bit slow, but it seems to have made a good improvement on the speed in Poser. (Still quite a delay, but better than before.) One thing I have noticed, nodes are killer. The more nodes you add, even to a simple scene, make Poser slow exponentially, not just incrementally. Nothing you can really do about that though, unless you don't use materials...

Poser is not abusing the swap file anymore than any other application as no application directly accesses the swap file. Windows handles all swap file activity. If there's not enough real RAM to satisfy the needs of all applications, Windows will use "virtual RAM" and that is from the swap file.

What ties up memory in Poser? Poser does:-) Both SamTherapy and Dizzi are correct. Poser asumes that a) it has got infinite memory and b) that the operating system will handle any problems. No-one has infinite memory and most operating systems assume that the user (application) will return unused memory gracefully. Alas, the twain shall never meet (unless, hopefully, in P7?) Memory should (usually) be handled by grabbing large fixed amounts (preferably in sizes of power 2), and the app should then do it's own, fairly simple, memory management internally. And release large bits when no longer needed. Doing this slows down the speed of the app. a little in the short term, but vastly improves both performance and reliability in the long term. There are plenty of reference books and items on the web explaining how to do this. Alas, so far, the Poser teams so far appear to have relied on graphics programmers, not systems programmers, for doing the programming, so memory is handled in a very unsophisticated manner.. Cheers, Diolma (Patiently waiting for P7)

Actually, Poser doesn't assume it has infinite memory...or at least it doesn't consistently. At the very least, it is held hostage by the 32 bit limit.

And Diolma, I'd have to disagree that every app should handle it's own memory management. For starters, very few people can do more than basic memory management well. There's no such thing as "fairly simple" memory management in anything but the most trivial teaching examples, and if your memory management needs are that simple, you're better off getting lumped in with the rest of the OS's memory management so that it can be smart about fragmentation and swapping. It isn't like you can isolate yourself from the memory use in the rest of the system anyway, and if you could, then you'd be a very badly behaved app to do so.

Many, many programs have memory leaks; unused memory that is not returned to the OS when it should have been. The OS itself also has memory leaks - no program is perfect, and no OS is perfect. Poser has larger memory leaks than usual. You can check that by freshly starting Poser with a default scene, note the memory usage (Task manager), then do all kinds of things and finish with File->New. You end up with exactly the same scene as when Poser has freshly started. Now look at memory usage, it'll be more than when you just started. The difference is leaked memory. This is why it's very advisable to save a scene after a couple of changes, and to save, exit and restart before starting a memory-intensive action - such as rendering.

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery   My freestuff

Hmm.... I wasn't trying to be controvesial, but I was trying to be simplistic (so laymen could possibly understand). I AM a systems programmer. So I know that memory handling can be difficult/awkward. It's just that there several techniques that help things considerably. Mind you, on thinking it over, one of Poser's problems must come from the fact that it's multi-platform; so what works on the PC may not work on the Mac (or vice versa). Plus they sub-contracted a lot of the work (so there was no real control over that part of the project) and improted 3rd party apps (like Firefly). Ah, well. Maybe my previous post was just me trying to show off my "superior" knowledge..... I agree that (almost) all apps suffer from memory leaks. Sometimes it is almost impossible to avoid, and with an app like Poser (especially with so much legacy code included), it wouldn't be possible without a complete re-write of the whole system, including the core. And that would be cost-prohibitive (yes, I do live in the real world). So, yes svdl, that's what I do. Save early and save often (like voting). And I save under at least a grandfather-father-son system, or else just simple sequentially named files. BTW - part of that "memory leak" is probably due to Poser's caching system (in materials, I believe, possibly elsewhere). It's a moot point as to whether that should be counted as a leak; it's deliberately retained. But then it can be argued that File->New should flush any cached stuff.. Cheers, Diolma

It's a moot point as to whether that should be counted as a leak; it's deliberately retained I have never understood why they have retained that beastly "pre-scanning" of content during the start-up of the program... I would rather Poser waited until I asked for a library before scanning it or what ever it is it does?

Just because Poser shows more memory consumed after being used and then reset to "new" doesn't make it a leak. If they are being smart and delay-loading libraries (and I mean DLLs), then those won't be in-memory until they get used the first time. There are other legitimate reasons Poser may consume that memory without it being a leak. Now, if subsequent File->New operations consume steadily more memory, that is good evidence of a leak. Is that what you see happen? By the way, Task Manager is a terrible thing to try to accurately track memory leaks with. To demonstrate this, take your "leaking" scenario and then minimize Poser. Task Manager will claim that Poser just gave back a bunch of memory, which it most certainly didn't. Perfmon is a better tool for this kind of tracking, though it is rather harder to use.