Quote - > Quote - in memory, because the larger my default runtime becomes the longer it takes Poser to load

Sure it does, as Poser builds the library dropdown... And Poser uses also uses/follows regualar file/folder shortcuts, so it's not too hard to answer why it's slowing down when the library gets bigger... Poser 7 added a timeout for the build action to its preferences, so those not using that dropdown can change that timeout to 0 to have Poser start up with the same speed no matter how big the library gets.

Well, building a drop down is one thing, but not unassing itself properly from memory, that's another thing entirely. 

If my default runtime gets to a certain size Poser will start crashing on renders, throwing error messages about not having enough memory.  Timeout or no timeout, it still won't render properly, it will crash and throw up a bunch of ugly dialog boxes telling me that there isn't enough memory to load certain texture files.

If I place the same items in additional runtimes (which also have to have library dropdowns built for them on the fly, it works fine.  However, if it's in my default runtime and that runtime gets to big,  it crashes and burns - so something other than just a simple "building of dialogs" is going on here.

No matter how you slice it, that's a programming problem.

-Never fear, RenderDog is near!  Oh wait, is that a chew toy?  Yup. ok, nevermind.. go back to fearing...