From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1J60ws-0007e4-0g for mharc-grub-devel@gnu.org; Sat, 22 Dec 2007 04:47:14 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J60wo-0007dr-51 for grub-devel@gnu.org; Sat, 22 Dec 2007 04:47:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J60wl-0007df-GO for grub-devel@gnu.org; Sat, 22 Dec 2007 04:47:08 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J60wl-0007dc-Ck for grub-devel@gnu.org; Sat, 22 Dec 2007 04:47:07 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J60wl-00021k-2n for grub-devel@gnu.org; Sat, 22 Dec 2007 04:47:07 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 7C7DF3EB23 for ; Sat, 22 Dec 2007 10:51:00 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 22 Dec 2007 10:47:04 +0100 User-Agent: KMail/1.9.4 References: <200712220906.33867.okuji@enbug.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712221047.05173.okuji@enbug.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Creating grub/grub2/grldr.mbr bootrom with makerom X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2007 09:47:10 -0000 On Saturday 22 December 2007 10:03, Bean wrote: > On Dec 22, 2007 4:06 PM, Yoshinori K. Okuji wrote: > > On Friday 21 December 2007 20:04, Robert Millan wrote: > > > How well does compression work for GRUB 2 ? core.img is already > > > compressed (with lzo); if LZMA makes better results perhaps it'd be a > > > good idea to switch. > > > > It's not that simple. LZO was chosen instead of gzip, because of the size > > requirement on PC. To preserve safety, we need to keep the core part less > > than 31.5KB (63 sectors). > > > > The size is the sum of non-compressable bootstrap code, decompression > > code and compressed code + data. When I made an experiment in PUPA, > > although gzip had a better compression ratio, due to the decompression > > code size, LZO won. > > > > I don't know precisely, but I suspect that decompression code for LZMA > > would be slightly larger than gzip's (IIRC, a range coder is likely to > > require more code and data). So I don't expect that LZMA can replace the > > current usage of LZO in normal PC so easily. > > The decompression code for LZMA is very small, i use -Os option to > compile LzmaDecode.c, the result is about 2.8K. Thank you for your information. In my estimate, LZMA will outperform, if the ratio, compressed size : original size, is less than 0.52. So LZMA might win. :) Okuji