On Fri, May 10, 2019 at 09:15:49PM +0100, Ian Jackson wrote: > dpkg-deb has a built-in decoder for the subset of ar that is used for > deb(5). One reason I chose ar rather than tar is that handwriting a > decoder for ar was much simpler than for tar.
I wonder then, why the speed loss? A good ar decoder should be able to peel away that layer without any difference: you just tell the tar decoder that it has a tarball X bytes long. (Ar members are always contiguous without holes or sub-blocks, right?) A stock library like libarchive has to be able to handle arbitrary filters, the vast majority of which are not transparent zero-copy. Thus, I understand why my experiments show the difference with a libarchive-based backend[1]. But if dpkg is faster with 0.939, that's an obvious missed optimization. Meow! [1}. libarchive claims to be zero-copy here but it splits the input into tiny blocks. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Historic linguists analyze word roots, right? So 4294967296 is ⢿⡄⠘⠷⠚⠋⠀ a core constant for them? ⠈⠳⣄⠀⠀⠀⠀