The library scans folders one level below what you see. If you open a runtime library in a given category and it has 20 folders, each with 20 folders or items below, then 400 items will be scanned. If you have 1 folder, with 400 items below, 400 items will be scanned.

Splitting runtimes can help, but so does splitting folders. The important factor is simply how many items must be scanned when you open a branch in the library. If you split them in such a way that there are still 400 items to be scanned, then you won't gain any time back.

To really gain speed, you want to cut down on how much must be scanned when you open something. This usually requires that you insert another level of folder and split the existing tree into multiple branches.

Imagine you have a props folder in some runtime that has the following folders:

A (and 20 items under that)
B (and 20 items under that)
...
Z (and 20 items under that)

When you open this runtime in props, you immediately are presented with 26 folders, A through Z, and the library scans the insides of those as soon as it shows you a label (A, B, etc.) for any of those. If you can see all 26, then it will immediately set about scanning 26 * 20 = 520 items.

Now suppose you create four new high-level folders and rearrange the content like this:

AtoG (and you move A through G inside this folder)
HtoN (and you move H through N inside this folder)
OtoT (...)
UtoZ (...)

Now when you open the props folder, you will see those four folders and the contents of those will be scanned. Since collectively there are only 26 items in all four together, only 26 items will be scanned instead of 520. And these are folders, not content, so they are cheap to scan. (Items must be examined, whereas with folders all you get is the name and date info. Particularly bad are pose files, since they must be opened and parsed to find out if they are animated poses and how many there are. 520 pose files takes a long time to scan.)

If you then open one of these, such as AtoG, then the subfolders will be scanned - A, B, C, etc. But there are only seven of those in AtoG, so the items needing scanning upon that action are only those 140 items in that branch.

So - if you really want to reorganize, splitting runtimes or folders alone won't really do it. You would do best to create another level of organization and put things in that organizational structure so that you group the things you use together in the same folder, and things you don't use together in different folders. Then you won't be opening (and scanning) things you have no intention of using in the current session.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)