Re: [Chicken-hackers] [PATCH] better line-number tracking

[Peter Bex]

On Mon, Feb 27, 2012 at 10:36:04AM +0100, Felix wrote:
> The attached patch adds various enhancements for keeping line-number
> information.
[..]
> This will report line-numbers correctly for code produced by
> syntax-expansions in scrutinizer messages and warnings.
> "compiler-typecase" does now keep line-number info to ensure errors
> generated by it will provide some hint at the exact location (it would
> be quite unhelpful otherwise). Debug-output for contraction and
> inlining will now report the line number of the call (if available).

Fantastic stuff!  Thanks Felix, I've pushed this change.

> The time spent during the canonicalization pass in the compiler is now
> roughly doubled, at least for the few tests I made. Note that this is
> only in the compiler, not csi.

In some of my tests (of course on some pretty horrible test cases),
it nearly tripled or quadrupled.  However this is such a useful addition
I think it's important to get this in nonetheless.  And in the numbers
test, it "only" adds 10 seconds to the total runtime, which is not
*that* much on 1.5 minutes.

I tried tweaking the hash table size (it's initialized to a rather
small size) but interestingly enough that had almost no effect at all
on performance.  The main reason of overhead is that a lot of
expressions end up under the same hash value because the car of each
expression is used as key.  Luckily, macro-renaming helps spread out
the population of the hash table more, but the worst offenders are
things like "car", or "lambda", which is going to occur pretty often
in most normal code.

Searching through the list of expressions that all map to the same
initial symbol seems to take quite a lot of time.  A better hashing
strategy would help, but unfortunately I don't know of a better way
given the existing code.  Most things I thought of would be more
expensive to hash, which probably makes hashing soak up the time that's
now used by the searching the list below the hashed key.

Possibly cons cells (and maybe other things) could be expanded to
have three slots instead of two, so they carry a line number; in that
case it would be O(1) to look up the line for an arbitrary expression.
However, this would make the memory storage requirements of any list
balloon up by again half its size. Especially in "normal" code that
doesn't run in the compiler this overhead is silly.

Anyway, thanks again, Felix.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth