[cffi-devel] Re: Strange Performance Issue

Mikael Lax mikael.lax at bredband.net
Mon Sep 3 19:12:23 UTC 2007


On Mon, 03 Sep 2007 18:21:43 +0100
Luis Oliveira <luismbo at gmail.com> wrote:

> "Luís Oliveira" <luismbo at 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



More information about the cffi-devel mailing list