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

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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 23:56:33 +0900

 joerg@ wrote:
 
 > Let me rerpeat: please stop calling people names. I have explicitly
 > asked about *measuring* things because cutting it out.
 
 Sorry, no motivation or benefit for me to measure it.
 
 > 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.
 
 > 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.
 
 > 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.
 
 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.
 
 Looking at code might take only five seconds, but
 implementation is often annoying and boring.
 
 ---
 Izumi Tsutsui