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


#1

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?


#2

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?


#3

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.


#4

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