is faster startup the only benefit of loading personal files with a partial menuload
rather then having your files load in "yourmenu.mnl"?
There's no efficiency benefit between adding your code to a "Custom".MNL, or AcadDoc.LSP, or S::Startup, or whatever else (or at least negligible).
The main issue about where you place these startup loading calls is about "portability". It's much easier to maintain your code if it's in one place, and having it in a MNL linked with your own partial MNU/CUI/CUIx makes it a "quick" task to install your lisps (and other) into another PC / Upgrade. I.e. instead of "debugging" each item to see if you need to copy-n-paste yet another portion of code into your new Acad.LSP or (G-forbid) adding yet another LSP into your Stratup-Suite ... you can simply load your MNU/CUI(x) as partial into the new ACad. That way you still get the full new CUI from your version of ACad (including all the new commands) and on top of that all your customizations. If you simply recreate a new Primary CUI/MNU you'd either miss out on some of the upgrade features or have to import them each time you upgrade.
Regarding adding a path to your support folders: It's no a bad idea, as it makes these load calls a lot simpler. Just remember to ensure that such paths are actually available. A lot of slow loading is due to paths in the support folders not being available (e.g. Network not connected / faulty, or even just a renamed path somewhere). If such path is not available, acad still tries to load the file by searching through each of those support folders - waiting for Winblows to error out an tell acad it's not found (for each of those folders) - thus it could drastically slow down startup and opening of DWGs :realmad: , even with the fastest possible PC. The idea around obtaining the path from the CUI is twofold: (1) It makes installation even easier as there's only one thing to do (i.e. load the CUI); (2) If the path cannot be found, then the CUI would not have been loaded in the first place - so less slow loading (theoretically :pissed: ).
Regarding use of load as opposed to autoload: Generally there's not much difference - especially with large RAM and fast PCs. I just tend to try not to load unnecessary stuff as much as possible. The AutoLoad idea makes for one case where you can have the function available but not yet loaded into RAM. Unfortunately its a lot more complex, and as shown has quite a few problems of its own (not insurmountable but still
). My rule of thumb is to load everything which needs to be loaded from the start (e.g. reactors, aliases, redefinitions of commands, etc.) and autoload those things which are only used once in a while (e.g. special extra commands, library functions only needed in special cases, etc.). That way I can have all my commands / library functions run smoothly with a minimal impact on load times and RAM use.
But definitely you need to keep your customizations as structured as possible. A messy list of LSPs and folders can only steer you into trouble, no matter what method you use to load them. A little bit of forethought could save endless headaches later. It becomes an exponential task with larger collections of customizations, but the debugging is also expounded, not to mention compounded
. So why not make your later life easier by putting some planning in beforehand?
