Quote - As I said, it does need to do that for the library dropdown menu... That triangle thingy on top of the content you're seeing for the current library directory you're in, that allows to navigate through the entire library structure without clicking up and down through the library. So as I said, if you don't use it, set the timeout so low that it doesn't bother reading the library for too long.

Ok, couple of quick things here just to set the record straight.  First, I am a software developer by trade, so I am aware of how most internal program mechanics work.  I understand you meant no disrespect, however in this particular instance I must point out that Posers "library reading routine" is horribly written.

It does not, for example, have the same problem when accessing additional libraries - they can be examined more or less on the fly without major impact on program performance or available memory.

However, once the primary library structure is loaded into memory, if you are correct and that is indeed what poser is doing at startup, it never relinquishes that memory again.  That is bad programming, no matter how you slice it.

First, there is no need to load the entire structure into memory in the first place, it's overkill and quite wasteful to say the least.  Posers "Library" is split into various sections, Figures, Props, etc..

The only thing required when the program starts or when the library is opened is for it to read the top level listing for whatever directory the library is pointing too at the moment.  It isn't necessary for it to load the entire listing of files and directories in the entire library at that point in time, it could easily do so on demand with almost no noticeable difference in speed on most modern systems.

Instead, assuming your theory is correct, it would seem that Poser loads the entire listing of files in it's default library into memory.  Ok, this in and of itself would be very wasteful and a bad design, however it would seem that the problem compounds itself in the fact that even if you switch from Posers default runtime to a "additional runtime" that memory is never freed up again.  It stay's locked up until you exit Poser.

And that is just really, really horrible code.  If that data is not needed there is absolutely no reason in the world why it should be sitting in memory taking up huge amounts of space and interfering with other program functions like rendering as a result.

Now, this is all assuming that you are correct and that is what Poser is doing, since I haven't seen the source code I can't say for certain this is the case, however it seems like a logical guess as to why a large default runtime would so negatively impact Posers performance.

However it is interesting to note that if such is the case then apparently they used different routines for accessing "additional runtimes" as opposed to the default runtime, as you can load a very large "additional runtime" and have the directory listing for it up and render just fine, so it doesn't seem to need to index every directory and file in it's additional runtimes the way we are assuming it does with it's default runtime.

And that in and of itself should be proof positive that if your assumption is correct then obviously they did not code the routines for handling the default library properly.  If they had simply used the same routines they do for additional libraries it wouldn't cause this problem to occur, other wise having a large "additional library" and loading it would cause the same problem.

Hopefully that clarifies my point.

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