Re: [PATCH] File readahead buffering

[Colin D Bennett <colin@gibibit.com>]

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

On Tue, 22 Jul 2008 14:48:31 -0400
Pavel Roskin <proski@gnu.org> wrote:

> On Tue, 2008-07-22 at 08:43 -0700, Colin D Bennett wrote:
> > This patch speeds up loading a TGA image on my test system from 29
> > seconds to approximately 1 second.
> > 
> > I noticed that on my 1 GHz test system running from an IDE
> > CompactFlash drive, loading a certain TGA image in GRUB takes about
> > 29 seconds.
> 
> I'm sorry for straying from your point, but maybe we should drop TGA
> support.  It was the first image format for GRUB to support, but now
> PNG is supported, and it should be better in all aspects.

I agree that TGA is not, in general, a great choice for an image format
(unless it is faster to load a large background image -- a 1024x768 RGB
PNG file may take more time to decompress than a TGA image would take
to load -- although perhaps an uncompressed PNG file would be
comparable in speed to load).  However, I have not been able to load any
PNG images that I have tried to use. Something about the chunk type not
being supported.

> > It turns out that when booting GRUB from IDE, if file buffering is
> > used, GRUB hangs right after the "GRUB" message, early in the boot
> > process.  So I added a flag that allows grub_main() to enable
> > buffering when it is safe to do so.  It always worked file from an
> > ISO image (generated with grub-mkrescue) in VMware and QEMU, but
> > when I actually installed GRUB to my CompactFlash drive and booted
> > it, it hung after "GRUB" if file buffering was enabled at the start.
> 
> I think we should be prefer simple and reliable code, rather than add
> complexity and risks of failure to achieve higher speeds.

If the buffering is not done in the file I/O layer, then the font
loading, theme file loading, image file loading, etc. will all need to
do their own buffering, which IMHO is more error prone and makes those
modules use more code to handle low level I/O stuff, which detracts
from their specific purpose.

Also, this is no small increase in speed, but from 10x to 100x increase
in performance for some cases where small sequential reads are
performed.

Regards,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]