Loading from InputFileStream is slower than projucer imported binaryfiles, why?

Hello!

So I’m building a binary loader for my plugin, so that all the files would be inside 1 package. I’ve used projucer before to just embed them into the resulting dll / plugin file, but now I’ll need so much files that projucer hangs up when trying to build the binarydata-files, and, ofc, it’s kinda akward to have a dll sized in GB’s. I created a simple packaging software that reads the files into 1 file with necessary info (filename, filesize etc). All is well and works, BUT it’s slow.

For some reason, binaries that are embedded in the code load, in my scenario, in 7 seconds when using the plugin, whereas the external pack I created loads in around 20 seconds. The difference is huge and 20 secs is too slow. If anyone could point me to the right direction, would be great!

Here’s a little snippet of the loading code:

void XAudioProcessor::loadSamples()
{	
		bool CABdataAvailable = true;
		File CABFile = "full path to the binary pack file";	
		ScopedPointer<FileInputStream> CABStream = new FileInputStream(CABFile);			
		
		while (CABdataAvailable) {
			
			//read sample name and size
			String Filestr = CABStream->readString();
			int64 FileSize = CABStream->readInt64();    			
			
			MemoryBlock SampleData;
			CABStream->readIntoMemoryBlock(SampleData,FileSize);

			//Do something with the data...
					

			//Stop if file ends
			if (CABStream->isExhausted()) {
				CABdataAvailable = false;				
				break;
			}
		}		
}

As you can see it’s very simple. Can anyone tell me why is this so much slower than reading embedded binary from the dll?

You probably shouldn’t be creating the MemoryBlock anew at each of your while loop steps. (You could put the MemoryBlock outside the while loop and just do a resize when you know the needed size.) Also, are you testing with a release build?

Hello!

Thanks for the reply! I tried your suggestion. For some reason MemoryBlock.SetSize() resulted in nullptr at some point when loading a sample (not showing in the code snippet above), but I changed it into just simple reset() and it works for now. There’s no clear difference in performance impact tho. :frowning: Yeah, I’m testing in Release build when not debugging something specific.

Maybe you will need to do some profiling on the code to see where it takes the most time.