Re: [Help-tar] Extraction performance problem

[Paul Eggert]

On 02/05/2015 10:57 AM, Jakob Bohm wrote:
> > The default is 20 (i.e., 20 x 512 = 10 KiB).
> Which happens not to be a multiple of 4Kio.

True.  The 10 KiB value has been the default since the 1970s, though; it 
dates back when computers often had only 32 KiB RAM. Changing it might 
break things, and we shouldn't change it without good reason.  A 
sufficient performance improvement for typical uses would be a good 
enough reason, but we'd need to see the numbers.

> > > has anyone tried to make a multi-threaded version?
> >
> > Not as far as I know.  It's not clear that going multithreaded would 
> > be worth the hassle.
> I would agree, but given the typical behavior of correctly
> implemented file system flush logic, it might pay to somehow
> overlap the closing of extracted regular files with the
> extraction of subsequent files (because close(fd) must imply
> fdflush(fd) which must wait for disk I/O

POSIX doesn't require that 'close' must flush buffers to disk, and 
'close' typically does not do that.  If you're on a system where 'close' 
flushes buffers, perhaps you can speed things up by configuring the 
system so that it doesn't flush buffers.  It sounds like your virus 
scanner is slowing you down, so I'd look into how it's configured.

Some of the optimizations you mention look like they may be worth doing, 
though we'd need to see benchmarks.