[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Compiler speed
From: |
Gabriel Dos Reis |
Subject: |
Re: [Axiom-developer] Compiler speed |
Date: |
06 May 2007 21:14:15 -0500 |
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