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

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

On Tue, Jan 12, 2016 at 12:35:01PM +0000, Martin Husemann wrote:
> The following reply was made to PR bin/50638; it has been noted by GNATS.
> 
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
> Cc: 
> Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
> Date: Tue, 12 Jan 2016 13:31:26 +0100
> 
>  And the ideal variant would do it in:
>  
>  >  non compressed kernel:
>  >  
>  >    1452589100:570546000: > boot netbsd
>  >    1452589150:429907000: Copyright(c)...
>  >    = 49.8594s
>  
>  + total time for one full decompression:
>  
>  # ls -l netbsd
>  -rw-r--r--  1 root  wheel  1827667 Jan 12 09:04 netbsd
>  # file netbsd
>  netbsd: gzip compressed data, last modified: Tue Jan 12 08:05:45 2016, max compression, from Unix
>  # /usr/bin/time gzcat netbsd >/dev/null
>         29.96 real        23.04 user         1.78 sys
>  
>  ... so like 80s.

This strongly suggests that a lot of seeking happens and the input is
processed multiple times. Is there a very good reason for not just
sucking in the whole kernel in one go or at least use a resize+read loop
once we know that it is an ELF binary we are interested in?

Joerg