[Ecls-list] ECL shootout

[Gabriel Dos Reis]

On Tue, Jun 30, 2009 at 4:02 PM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> On Tue, Jun 30, 2009 at 10:45 PM, Gabriel Dos
> Reis<gdr at integrable-solutions.net> wrote:
>> On Tue, Jun 30, 2009 at 3:17 PM, Juan Jose
>> Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
>>
>>>> I'm not claiming that use is typical of performance problems in ECL.  I'm
>>>> just offering data points (e.g. not artificially made up.)
>>>
>>> It is a pity that OpenAxiom is such a complex beast that I would not
>>> know where to begin for profiling it.
>>
>> Tell me more about how you do it (e.g. profile a standalone
>> ECL-based program), and I'll try to see how I can make that happen
>> for building the OpenAxiom compiler. (I do not use SLIME.)
>
> What I do normally for a full profile is
> 1) Build ECL with debug flags (-g -O2 seems ok) so that the compiler
> and linker keep track of function names.
> 2) Tweak my makefiles so that COMPILE-FILE gets a couple extra
> arguments :C-FILE T :H-FILE T that keep the C files around. This is
> needed sometimes to better locate the bottlenecks.

Thanks, I'll try to augment OpenAxiom build machinery with that, that
canbe triggered by --enable-profile.

> 3) Run the program I want to profile and inspect the logs
>
> For a very big program this sometimes gives an idea of what are the
> bottlenecks from the ECL library. However, I also like to profile test
> cases, small functions or pieces of code. The Gabriel benchmarks are
> ideal for that.
>
> Step 3 could be done with gprof or with OSX's Shark, but the latter
> does not work well with things that take a lot of time: it profiles
> best small functions, small pieces of code that take at most a few
> minutes.

Does step 3) work reliablly with shared libraries, e.g. libecl.so?  I
was under the impression that shared libraries are not well with
gprof?

-- Gaby