speed optimization idea?

It takes a long time to load sonar filled with VSTi instruments.    Generally, that's probably not Sonar's fault ... however
 
would it be feasible to NOT show the name of every single instrument as it is loaded?     On my system, it's all Kontakt, and there are approximately 5 x 16 x 40 = 3200 instruments loaded (kontakt .nki files, organized in kontakt .nkb banks).   While the names flash by very quickly, still that's a lot of display output for no benefit at all -- they go by too fast to read easily, but it takes a long time to put it all on screen.  
 
This might be a Kontakt function about which Sonar has no control - don't know. 
 

I imagine loading a few goes so fast you don't even see the screen.   Maybe the way I configure instruments is out of the ordinary -- there tend to be very many lightweight instruments so that articulations can change very frequently depending on the music. 

 All hail the block tool.....

The time required to load instruments comes from pulling the samples (probably at least several hundred megabytes) from where they're stored and either a) shuttling them into RAM if you stream from RAM, or b) separating just the attacks and shuttling them into RAM if you stream from hard drive. The display is just running in parallel with the loading process.

Move your most often-used libs to a solid state drive.  Otherwise, be prepared to take a lot of coffee breaks.

Just for fun I timed loading up Sonar with approximately 40 GB of samples, all from an SSD drive and presumably into memory only (?),   and copying approximately the same amount of data from an SSD drive to a regular SATA drive.  
 
It took sonar just under 7 minutes to load; completing the copy took just under 6 minutes.   
 
Now clearly writing to a regular drive is going to be way slower than reading from an SSD drive ... so ... what's taking all that time with sonar?    I've got a suspicion:   Sonar, or kontakt, or Windows, is writing all that loaded data to a working file located somewhere on my system disk (regular SATA).
 
I don't believe it's going to the paging file, it is set at a rather low size on the SSD manufacturer's recommendation (basically that the system should not use a paging file):  800 MB on a system with 64 Gb of memory.   (edit) -- confirmed this last, by changing to a very large paging file entirely on an SSDD drive --- no significant change in load time. 

williamcopper
It took sonar just under 7 minutes to load; completing the copy took just under 6 minutes.

Loading requires parsing the data - e.g., assigning to keyboard ranges and MIDI channels, separating attacks if you're streaming from disk, etc. A straight copy is just a bit-for-bit file transfer, no intelligence required.