FlushFileBuffers() - heavy performance hit


#1

I've just been trying to work out why a zip file containing about 150 files takes up to 20s to unzip, whereas a zip file of the same size but containing only a single file takes less than half a second.  I only really noticed this after moving to a Windows machine without an SSD, which ultimately led my line of thinking to FileOutputStream::flushInternal().

FileOutputStream::flushInternal() is called by FileOutputStream's destructor, and ultimately calls the FlushFileBuffers(), which is where all the time is disappearing.  Removing the call from the destructor speeds up the unzip by a factor of over 40 in my test case (150 files, 20MB zip archive).

Finally I should qualify this by saying I'm using a heavily modified version of Juce, but it would seem to be the same in the unmodified version (by inspection, I haven't tried it empirically).

I can't see any harm in leaving this out of the destructor (there's still the option of calling an explicit flush() if required), but I'll leave that to Jules to decide.

 

 


Issue after multiple files operations
#2

Hmm, very interesting!

I think removing it from the destructor is a good suggestion, and is probably safe. I'll have a think and will probably do that, thanks!