"Luís Oliveira" luismbo@gmail.com writes:
I didn't do any profiling but I guess that extra overhead I described explains the time difference. I'm not sure what's consing 700M though.
A quick profiling session reveals CHECK-FOR-TYPEDEF-CYCLES is the culprit, because it conses a fresh hashtable each time. This is called by PARSE-TYPE, which in turn is called by MEM-[A]REF in that inner loop in TEST-2. That's 786432 new hashtables.
TEST-2 with PARSE-TYPE modified not to call CHECK-FOR-TYPEDEF-CYCLES:
CFFI> (time (test-2)) Evaluation took: 11.782 seconds of real time 5.285146 seconds of user run time 0.307772 seconds of system run time [Run times include 0.145 seconds GC run time.] 0 calls to %EVAL 0 page faults and 22,016,008 bytes consed.
I suppose it might be worthwhile to look into some way of optimizing C-F-T-C. This check can probably be done when the type is defined, at least in some cases.