This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A basic question regarding [eCos] performance figures


On Thu, Oct 14, 2004 at 02:36:39AM -0700, sandeep wrote:
> when one cites various eCos performance figures
> related to footprint and timings for core functions
> (as printed via tm_basic tests) --
> 
> are those generated using certain compiler flags (like
> -O2, -Os etc.) applied during compilation and some
> linker flags for relaxation pass etc. during linking -
> to reduce code size and also have impact on execution
> timings.

They are generally for the default compiler flags.

Feel free to try other combinations to optimize for space/speed etc.
 
> also i would like to seek opinions of experts on - 
> is there any issue with the process of code-tweaking
> that is tied down to how the toolchain in question
> generates code with particular compiler flags, though
> this way it generates tighter object code, that would
> improve code size and speed? this kind of things can't
> be done for common code though.
> 
> sure, this might at times, render the source code, not
> easily comprehensible. but should this matter to me as
> a user, if i am not given the source code, just the
> binaries and needed headers.

Remeber eCos is GPL based. You have to make sources available to your
customer. Also modification you make to eCos must be made available to
your customer. If you don't do this you have no right to distribute
eCos at all in any form.

As for opimizing for speed, my experiance is there is little point
just tweeking things here and there. You need to target your
optimizations to your application and probably optimize the
application as well. Take a look at the output from a profiler running
the application. Optimizing the functions that are taking the most
time will get you the most gains. Sometimes you even have to throw
away parts of your current implementation to use different algorithms
which are more optimized for speed.

As for optimizing for space, i found i got most gain by looking at the
size of symbols in the overall application. I found some big
application buffers which could be tuned so saving lots of space.

The real trick with optimization is not the optimization itself, its
finding where to optimized.

        Andrew                

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]