<div class="gmail_quote">On Sat, Sep 15, 2012 at 7:36 PM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net" target="_blank">mm_lists@pulsar-zone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

At <a href="http://ecls.sourceforge.net/ecl/The-profiler.html#The-profiler" target="_blank">http://ecls.sourceforge.net/ecl/The-profiler.html#The-profiler</a> are<br>
listed a few functions, which despite building ECL with --with-profile<br>
appear to be existing yet unbound symbols.<br></blockquote><div><br></div><div>This belongs to the old manual, which is declared obsolete. The currently linked manual is the only valid one</div><div><a href="http://ecls.sourceforge.net/new-manual/index.html">http://ecls.sourceforge.net/new-manual/index.html</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also see in contrib/ a profile tool ported from SBCL, but<br>
unfortunately the SBCL documentation I can find seems to address<br>
another profiler (sb-prof).</blockquote><div><br></div><div>Well, SBCL has diverged since then, acquiring some tools to keep cross references and statistical profiling that unfortunately ECL doesn't have.</div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If I look at the source, the profiler appears to only be able to profile specified functions, when I'd like<br>
to have more complete profiling.<br></blockquote><div><br></div><div>The Lisp profiler is a bit invasive. There is no way for ECL to do full profiling by itself because it cannot intercept the function calls which appear in three forms: C calls, compiled Lisp calls and interpreted function calls. That is too complicated. The profiler is just intended to be used to get statistics of a finite subset of code, to see how it performs.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess that since ECL compiles to C it'd also be possible to use gprof<br>
and other C profiling tools, though.  But is there another recommended<br>
way?<br></blockquote><div><br></div><div>I have found OS X's statistical profiler to be the most useful tool. gprof tends to be very confused by ECL's deeply nested tree of function calls. "shark" instead just interrogates the program every few milliseconds or some smaller unit to know what the program is doing and gets very accurate reports. It also helps that one has a GUI to hide unwanted functions or whole libraries from the report.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have resumed a bit work on my httpd (now named Crow), and since<br>
yesterday it also hosts my personal site.  The server's hardware is<br>
modest compared to my development system (although Crow runs fine and is<br>
not slower than the previous js-written HTTPd which hosted my site for<br>
years), I'm at a stage where profiling would be nice to have, instead<br>
of blindly optimizing every function.<br></blockquote><div><br></div><div>I believe that a C profiler will be most useful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Optimizing is also a way to get better aquainted with ECL.  I noticed<br>
yesterday how rewriting URL-ENCODE differently increased its speed<br>
50-fold (it previously used REDUCE (with custom LAMBDA), CONCATENATE,<br>
MAP (with custom LAMBDA), FORMAT, as well as a CHARACTER-VALID-P<br>
function which was passed a dynamic variable as its table, all of which<br>
resulting in a tremendous amount of function calls for simple string<br>
processing).  It was elegant to read and fast to write, which was fine<br>
for early interactive development, but really had to be rewritten for<br>
production use (it now expands to efficient mostly inline C).<br></blockquote><div><br></div><div>I have been incorporating compiler macros for many sequence functions over the years and this seems to work quite well, but not all of them are covered. In any case REDUCE+CONCATENATE is not a very friendly couple in terms of resources: consing is to be avoided whenever possible, specially high-level consing which cannot be optimized away.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also discovered that CHAR<= couldn't be inlined as <= can, such that<br>
a macro expanding to CHAR-CODE and <= resulted in a significant speed<br>
improvement to test if a character is within an expected range (see<br>
<a href="http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/cl/server/character.lisp.diff?r1=1.4;r2=1.5" target="_blank">http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/cl/server/character.lisp.diff?r1=1.4;r2=1.5</a>).<br>


It's possible that the compiler only needs some small modification to<br>
allow inlining CHAR* functions, but I've not looked at that yet.</blockquote><div><br></div><div>The CHAR<= function uses the C library and cannot be inlined: its purpose is to compare characters according to some collation order, which of course has nothing to do with CHAR-CODE.</div>

</div><div><br></div>Juanjo<br clear="all"><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>