[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] advice
From: |
Camm Maguire |
Subject: |
[Gcl-devel] advice |
Date: |
05 Sep 2008 13:30:53 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! When tuning lisp performance,
1) What is considered a good balance between gc time and non-gc time?
I.e. when does one stop worrying about generating garbage?
2) The rate limiting step in the compiler now (which is getting rather
peppy these days), is type-and. GCL computes unique types in
standard lisp (i.e. list) form, and eq hashes the normalized
result. type-and is guaranteed to receive two such normalized types.
Right now, we check each in an eq hash-table which returns a
hash-table, in which we check the other for a possibly precomputed
result. We only cache a hardcoded list of 'useful' types for this
purpose. Failing that, we cons on the stack `(and ,t1 ,t2),
uniqueify this, which requires a slow 'equal hash, normalize and
simplify and return the result.
This seems a lot like your hons mechanism, i.e. quickly returning a
unique object as a function of two other unique objects. What is
the best cache-management/hashing algorithm here?
Take care,
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] advice,
Camm Maguire <=
- Message not available
- Message not available