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 16:53:10 +0100

 On Mon, Jan 11, 2016 at 03:00:01PM +0000, Izumi Tsutsui wrote:
 >  > I am quite aware of the limited resources, both CPU time
 >  > and space.
 >  
 >  I meant limited human resources. If you have enough spare time
 >  to try it, it's fine and no reason to ask other guys.
 
 I haven't hit the problems and I don't have hardware easily at hand that
 is slow enough that it matters.
 
 >  > They are not used by default, that doesn't mean it is not used at all.
 >  
 >  If someone complains slowness on x86, others might look at it.
 >  That's all.
 
 It is not noticable on semi-modern hardware. Even the slow version takes
 less than 1s, IO is still worse.
 
 >  > 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.
 >  
 >  The fact is not so simple.
 
 Yes, the fact is that simple.
 
 >  For example, persons who added crc32() into libkern didn't
 >  change the function name but did change an argument type,
 >  then it caused a conflict against the original zlib one.
 >  I cannot simply use zlib/crc32.c and I have to copy code
 >  from zlib/crc32.c to slightly modified libkern/crc32.c.
 
 I mentioned the code specifically because it is much easier to use than
 the copy & pasting from zlib's dynamic table compution, which is might
 be somewhat faster for larger input, but also is larger in terms of code
 size. If you had looked, it would be have been quite clear.
 
 Joerg