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

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

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