[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

getting compiled franz to run faster



	Part of the reason why many have not had much success writing franz
programs which run at a reasonable speed is the lack of knowledge about
some important features.  Most important is to avoid expensive time in
function calls.

	Below is a list of some suggestions for achieving significant
speedups:


(1) Don't use the interpreter unless you really have to.  It's not that
difficult to get programs to compile in franz.  If you do use the
interpreter, make sure displace-macros is set to t.  Otherwise macros will
be expanded each time they are called, causing horrendous slowdowns.

(2) Run programs with (sstatus translink on).  This can give up to a 50%
speedup.  Tracing automatically turns translink off, and you should turn 
it off manually, (sstatus translink nil), when using the debugger.

(3) When running debugged programs, you can get a large speedup by declaring
most of your functions to be local: (declare (localf ...)) .  This avoids
any time in the transfer table.  Of course, calls to these functions will
no longer appear on the stack, so it's not advisable while debugging.  In
the Berkeley AI research group, we have production-mode versions of our 
programs which declare all possible functions local and use ``include'' 
to contain the non-production version.

(4) Use open-coded functions.  The following is a list of some commonly-
used functions and their open-coded versions (many franz users have other
versions of common functions which are also not open-coded):

	Function			Open-coded version
	________			__________________

	lessp, greaterp			>&, <&
	add1, sub1			1+, 1-
	plus, minus			+, -
	
	. . .				. . .

(5)  Compile macros.  Write cmacros or declare ``macros'' to be t while
compiling.

(6)  Allocate sufficient storage space while compiling and running programs.
The garbage collector will get around to establishing more space, but it is
better to start with a lot of space for a large program.


	paul (jacobs@berkeley)