Quote - The path contained in the scene directs the OS to look up the exact location of the file in the File Allocation Table (FAT: Win9x, WinME, sometimes WinXP), the master file table (NTFS: Win2000/XP/Vista) or whatever the system is called in OSX. Then the OS will retrieve the file on behalf of the application.
This is how ALL file retrieval works, in EVERY app (unless the app overrides this behavior, as is the case with low level utilities such as disk defragmenters, virus scanners, disk imaging software and the like).
So Poser doesn't have to be slower than any other app when it comes to file retrieval. Unless it does some very inefficient processing before actually retrieving the file.

And the amount of available memory after that process should stay the same, whether the runtime in quesiton was tiny or huge shouldn't matter.  If it isn't actually loading anything into memory there is no reason why available memory should decrease.

And yet, for whatever reason, it' s been my experience that the larger that Posers default runtime gets, the less available system resources it seems to have for other things (like rendering).

It makes no sense of course, it shouldn't matter if the default library is huge, there is no reason whatesoever to read through the whole library at startup and put any information into memory, other than a single listing of file folders/files in one directory for the list you would see in this window on startup.

But apparently this is not what poser does, it seems to be reading in something, perhaps the entire directory structure, and then not unarsing whatever it is from memory.  It's  definate program bug and hopefully one they'll get around to addressing soon.

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