Re: [spr8255] Labels are slow!

[duane@franz.com (Duane Rettig)]

>> Could someone from Franz explain some of the issues involved with this
>> example, so we users can look for analogous problem spots in our
>> current code?  Is the problem simply the extra function-call overhead,
>> or is it that the LABELS functions are closures, necessitating the
>> dreaded COPY-FUNCTION.

LABELS and FLET functions are (of course) compiled as closures when
lexical variables are closed over.  In addition, a LABELS function
that refers to another LABELS function (either indirectly by calling
it or by treating it as a first-class object) also creates a closure.

In the example code:

(defun test1 (cnode)
  (LABELS ((ZGEN-580 NIL
	     (DECLARE (INLINE ZGEN-579))
	     (OR (AND (EQ CNODE 'A) (ZGEN-579))
		 (AND (EQ CNODE 'B) (ZGEN-579))
		 (AND (EQ CNODE 'C) (ZGEN-579))))
	   (ZGEN-579 NIL (symbolp cnode)))
    (ZGEN-580)))

the variable CNODE is closed over by both LABELS functions.  Even if
ZGEN-580 did not refer to CNODE, its reference to the closure ZGEN-579
would by itself also have been sufficient to cause it to be
implemented as a closure.

In Allegro CL 4.1, the creation and calling of closures is slow.  We
also recognize that in certain cases, some level of "open-coding" can
eliminate the internal functions altogether. In order to do so, the
internal functions must provably never be used as first-class objects.
(There may be some inlinable cases where they are indeed be used as
first-class objects, but in no cases can the function objects be made
externally visible, e.g. by returning the function, etc.)

Our first step in fixing this speed problem was in making closures much more
efficient.  In Allegro CL 4.2 beta, functions are never copied in order to
create closures, and the code itself is much smaller and faster.  We have
made some further improvements to this in 4.2 beta2 (due out very soon).

Our second step will be to enhance the data-flow analysis to recognize
those internal functions that are never used as first-class objects,
and to transform their code inline.  "Inline" here covers a number of
techniques beyond simple inlining of the code, but they are
semantically equivalent.


>> I tend to use internal functions a lot, and I'd really like to know
>> what the tradeoffs are, if they're as dramatic as this example seems
>> to indicate.

It should not be necessary to recode your application to not use internal
functions, since we are highly motivated to fix those problems with
inlinable cases; you could run the profiler on your code and just
modify those functions that show up high on the flat profile.
Also, Allegro CL 4.2 should be of immediate help.


>> John Burger
>> john@mitre.org

Duane Rettig, Franz Inc.        1995 University Avenue, Suite 275
duane@Franz.COM (internet)      Berkeley, CA  94704
uunet!franz!duane (uucp)        Phone: (510) 548-3600; FAX: (510) 548-8253