Re: [Axiom-developer] Compiler speed

[Gabriel Dos Reis]

Waldek Hebisch <address@hidden> writes:

| Using sbcl profiler on Maitin's guessing package I identified
| some time sinks:
| 1) extendLocalLibdb function (which is called at the end of each
|    compilation).  This function looks generally bogus -- it tries
|    to update libdb.text but is producing garbage (correct libdb.text
|    is built later, when databases are rebuild).  Together with
|    addPatchesToLongLines this function caused sbcl to run out of
|    memory on 512 MB machine (extendLocalLibdb is responsible
|    for producing some long lines while memory usage of
|    addPatchesToLongLines on sbcl is quadratic with respect to
|    its argument).  What matters for time usage is quadratic
|    union algorithm which extendLocalLibdb calls on old
|    content of libdb.text and new lines.
| 
| 2) profileRecord function -- conses a lot and takes a lot of time.
|    AFAICS the information collected by profileRecord is unused.
| 
| 3) searchCurrentEnv function -- apparanetly this function implements
|    the main compiler symbol table using linear search.
| 
| After eliminating the first two problems profiler indicates that
| about 60% of execution time goes into linear searches done by
| searchCurrentEnv.  I found some possibility for improvement
| here: some searches can be easily eliminated.  But ATM I do not see
| how to get major improvement without a compiler rewrite: the symbol
| table is shared with interpreter and both compiler and interpreter
| in many places have dependency on current form of symbol table.
| Also, compiler uses symbol table is such a way that it is not
| clear if different form of symbol table would be more 
| efficient.

Yes.

I'm rewriting part of the compiler in Spad -- it will take some
time before it gets fully functional, but I do hope to make
progress by the summer.

-- Gaby