On Mon, 03 Sep 2007 18:21:43 +0100 Luis Oliveira luismbo@gmail.com wrote:
"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.
Thank you very much for your response Luís, it was quite useful to me. One thing I realize I didn't point out very well in my initial mail was that the code in cl-opengl that loads textures from lispy arrays currently expands into the horribly slow test-2 case. Just a heads-up to any cl-opengl users.
Sincerely, Mikael Lax