This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: ELF loader slowness & getc_info help
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Matthew J Fletcher <amimjf at sky dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Sat, 25 Apr 2009 08:10:08 -0600
- Subject: Re: [ECOS] ELF loader slowness & getc_info help
- References: <49F2BF6B.60500@sky.com>
Matthew J Fletcher wrote:
> Hi,
>
> I have a pretty large C++ application which when uncompressed is about
> 16mb in size (8.5 when gzip compressed).
>
> Loading this from a flash filesystem to memory takes about 50 seconds, a
> bit of diag_printf()'ing shows that 40 seconds of this time is taken in
> the 'ch = (*getc)()' function in load_elf_image(), not surprising given
> that its called 16 million times for my application.
>
> A quick hack to read 32k blocks takes the time down to about 15 seconds.
> Unfortunately the complexity of interacting with getc inards means the
> the resulting memory layout is not quite right.
>
>
> My idea was to use the getc_info directly to avoid all the extra calls
> to getc, which resulted in the following code,..
>
>
> -- snip --
> // handle length to read
> if (len >= BUF_SIZE)
> read_size = BUF_SIZE;
> else
> read_size = len;
>
> // Copy data into memory
> while (len > 0)
> {
> getc_info.bufp = getc_info.buf;
> getc_info.len = (*getc_info.fun)(getc_info.bufp, read_size,
> &getc_info.err);
> getc_info.avail = getc_info.len;
>
> for (i =0; i < getc_info.len; i++)
> {
> *addr++ = *getc_info.bufp++;
> offset++;
>
> // knock off what was read
> len--;
> getc_info.avail--;
>
> if ((unsigned long)(addr-addr_offset) > highest_address)
> highest_address = (unsigned long)(addr - addr_offset);
> }
>
> if (getc_info.err)
> break;
> }
> -- end --
>
> Are there any ELF loader experts out there, or redboot getc internals
> experts that could shed some light on the brokenness of my hack/patch ?
I see plenty of things to comment on, but without knowing where this
code lives and how it's being called, I hesitate to say much.
A patch against the current tree would be much simpler to work with.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss