This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ecos performance
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Cc: Stijn Symons <stijn dot symons at gmx dot net>, eCos Discuss <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 5 Apr 2002 10:54:05 +0200
- Subject: Re: [ECOS] ecos performance
- References: <007f01c1da2d$28789860$8304040a@AJIDICA> <3CABEDD6.F11D01BA@redhat.com>
On Thu, Apr 04, 2002 at 07:08:22AM +0100, Jonathan Larmour wrote:
> Stijn Symons wrote:
> >
> > Hi all,
> >
> > were still trying to speed up things with are Java VM on eCos. We've got
> > it a little faster, but still it's significantly slower than embedded
> > linux. Our question is: we use queue's and memory pools heavily. The
> > pool is +/- 15 Mb and the queue's are used to zip/unzip all the class
> > files.
> >
> > Is it possible that it could be these that slow down the program?
>
> Not intrinsically - but maybe the *way* your using them is the problem
> (e.g. a zillion 1 byte allocs and frees etc. :-)).
>
> We've been developing profiling technology (with gprof) for some customers,
> but it won't be used with eCos apps (it's to do with other apps loaded via
> RedBoot). This is probably the type of thing you need to have developed to
> work out what's happening.
If you look a long way back in the archive, Dec 1999, you will find an
email which contained a basic profiler. It was for the ARM EBSA285,
but the basic code can be ported to other platforms with some
work. That will gve you an idea which functions are taking up the
time.
Andrew
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss