Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

The following reply was made to PR bin/50638; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
Date: Mon, 11 Jan 2016 12:44:51 +0100

 On Mon, Jan 11, 2016 at 10:50:01AM +0000, Izumi Tsutsui wrote:
 > The following reply was made to PR bin/50638; it has been noted by GNATS.
 > 
 > From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
 > To: joerg%britannica.bec.de@localhost
 > Cc: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
 > Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
 > Date: Mon, 11 Jan 2016 19:45:26 +0900
 > 
 >  joerg@ wrote:
 >  
 >  > >  > >  > (3) completely disable gunzip crc32() calculation in cread() function
 >  > >  > >  
 >  > >  > >  My vote is on (3).
 >  > >  > >  
 >  > >  > >  Thanks for dealing with this!
 >  > >  > 
 >  > >  > Can you try the faster crc32 from libarchive? It doesn't add much code
 >  > >  > and IMO having the verification is quite useful.
 >  > >  
 >  > >  It looks like Armchair Detective's comments.
 >  > 
 >  > Can you please try to avoid calling people names without even looking at
 >  > the suggestions? We have been running into a situation very similar in
 >  > libarchive, where the original dumb crc32 implementation created
 >  > significant performance impact. The new fallback version is only
 >  > slightly larger than the dumb version, both in terms of number of source
 >  > lines and code size. It was fast enough for libarchive's purpose and it
 >  > should be fast enough for input the size of the ramdisk kernels on
 >  > slower systems.
 >  
 >  Consider paticular use and background of libsa cread.
 >  You are claiming the perfect world without consideration
 >  of cost vs benefit. Unfortunately we have very limited resoures.
 
 Let me rerpeat: please stop calling people names. I have explicitly
 asked about *measuring* things because cutting it out. You obviously
 still haven't bothered looking at the suggestion since it even has some
 hard numbers. I am quite aware of the limited resources, both CPU time
 and space. That is exactly why I offered a version that is known to be
 almost the same size and significantly faster.
 
 >  On i386 and amd64, gzipped kernels are not used at all.
 
 They are not used by default, that doesn't mean it is not used at all.
 For booting from ISO images, it would likely be a net gain in terms of
 boot time, but doesn't matter in terms of size win.
 
 >  Using existing code (including zlib DYNAMIC_CRC_TABLE version, which
 >  was used by 4.0 and prior) or removing CRC caluclation is acceptable
 >  compromise for me, but I don't have extra motivation to pull
 >  whole new infrastructures in this case. That's why I proposed
 >  three approach in the PR.
 
 Have you spend even 5 seconds to look at the file I pointed to? There is
 no new infrastructure. It is pretty much a drop-in replacement of crc32
 with a dynamic single byte table computation.
 
 Joerg