Hi Anthony,
No problem to answer the question, if only the question would be clear ...
I mean, to me you are comparing apples to motor bikes;
Embedded Explorer is an Explorer instance, but embedded in XXHighEnd('s GUI). You could compare it (for speed) to normal Explorer if you want, but you will find nothing different.
A Gallery contains Meta Data, hence small files (1 KB) representing the real files (multi 10 MB).
Can anything be more fast in there than a folder with real data ? no, I don't think so. It's just a "table of contents" showing.
Do notice that a Gallery folder also holds the real Coverart files.
So :
are Galleries quicker to load than the embedded Explorer?
should be something like :
are Galleries quicker to load than real files ?Yes they are.
But now for very different reason :
First off, the disk holding my Galleries is the fastest one for read speed I own (it's an SSD but alas). Now :
What shows in the Library Area (!) is the Coverart from that SSD. This really has to be read from disk for its data. So, if the Coverart is 500KB, 500KB is to be read from disk (SSD etc.). If 20 pictures show in the Library Area (per page), 10MB has to be read from disk (it is cached, but any first time per XXHighEnd session it's read from disk).
Say that an SSD is 5 times faster for reading than any normal disk (holding the real music files). Well, then when you do not use Galleries, it shows 5 times more slow (which is quite a lot).
Also, you will find HUGE differences in speed over the various disks you (may) own. The one really is 3-4-5-6 times faster than the other. So without Galleries you depend on the speed of the disks, regarding what shows in the Library Area (load time of the album, same thing, but obviously you do that less frequent than selecting albums out of shown 20-40-60 etc.), which makes the importance of Coverart reading higher than the real file reading.
There's more to tell but I hope this suffices for the general idea. However, one crucial thing I will add :
When we don't have any local storage, we thus pull the Coverart (showing in the Library Area) over the Network cable. This is relatively super slow (think that it in normal circumstances can do 100 Mega Bytes per second while the fast SSD does ~500 Mega Bytes per second. So now you suddenly have another bottleneck which did not exist a year ago (for you), because you had all stored locally. So with 500 KB pictures, 200 per second (200 x 500KB = 100 MB) can travel your Ethernet cable. Fast enough ? yes. But still 5 times more slow than when dealt with locally.
In the end all adds up.
Notice that there is a reason for the (RightClick) functions in the Coverart pane (right hand pane of the three). A lot in there is about squeezing down the unnecessary (scanned) large multi MB coverart into smaller ones, of as good quality. This should only be done for the front coverart, as that is the coverart to show everywhere in selections, WHILE the remainder of the coverart is to stay as large as you like(d to scan it) because otherwise the very small print won't be readable on the screen.
Peter
PS: By sheer accident I recently have spent many days by now (and still working on it) to make blasting (scroll) speeds of Library Area contents. So it could come across as shocking that I can now scroll through my 40K+ albums as fast as I can move the mouse up and down in there. Meaning : I scroll through all the 40K+ items in 0.1 second. That's only 1 million times faster than you still have it in there. Mind you, this is scrolling. Showing is something else but that too improved with a few factors.
If only (much) time is spent on such things, it can be way more smart. That's with all in computing. But all is about priorities just the same. Or when things
become (require)more priority ...
