anthwlock / untrunc

Restore a truncated mp4/mov. Improved version of ponchio/untrunc
GNU General Public License v2.0
1.87k stars 182 forks source link

Speed up writes on Windows #99

Open jbruchon opened 2 years ago

jbruchon commented 2 years ago

You should change the code such that when compiled for Windows, the following line uses "wbS" instead of "wb" for caching optimized for sequential operations:

https://github.com/anthwlock/untrunc/blob/3cf5947849b79792b2fb357650d34792cf061c52/src/file.cpp#L206

It slightly speeds up benchmarks for sequential reads and can't possibly hurt for sequential writes.

Also, any other fopen() calls for data that will be mostly sequentially accessed should have the S added to the Windows file mode string as well.

anthwlock commented 2 years ago

https://rotoglup.blogspot.com/2009/06/few-performance-tests-on-sequential.html

Am I missing something, or did this flag only have an impact on Windows XP?

Adding this flag to the code would also add some complexity. First because it is windows only, second because for reading, the sequential flag would be useful for the broken file, but (probably) not for the healthy file. (One could add a new parameter use_seq_flag to FIleRead::open)

jbruchon commented 2 years ago

That page shows an improvement on Vista; notably, no one seems to have published any benchmarks for 7, 8, 10, etc. Even a marginal improvement is still an improvement, and the optimization for sequential I/O doesn't mean that random I/O will suffer unless the workload is more random than sequential. Since it's video, even if chunks of data are being accessed randomly, the chunks themselves are sequential and of significant size.

Here's an example of how I do this in my code:

#ifdef ON_WINODWS  // defined in Makefile using ifeq ($(OS), Windows_NT)
#define FREAD_MODE "rbS"
#define FWRITE_MODE "wbS"
#else
#define FREAD_MODE "rb"
#define FWRITE_MODE "wb"
#endif

fopen(filename, FREAD_MODE);
fopen(filename, FWRITE_MODE);