On Mon, 03 Sep 2007 18:21:43 +0100 Luis Oliveira <[EMAIL PROTECTED]> wrote:
> "Luís Oliveira" <[EMAIL PROTECTED]> 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 _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
