[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