evaluating CLOS performance

[Jon L White <jonl@lucid.com>]

As someone who has been trying to improve lisp compiler performance
to help CLOS and PCL, I can well sympathize with your analysis of 
the complexity in evaluating CLOS performance.  While acting as one 
of Dick Gabriel's correspondents on the Lisp Timings project (whence 
came the book "Performance and Evaluation of Lisp Systems), I many
times saw the tendency of people to pick one facet of a 1000-facet
system and focus in on it as THE measure.  [Of course, when several
facets have wildly differing values, one can seldom find a single 
statistical summary of them that is satisfactory to every end user.]

CLOS _by itself_ is at least as complex as the Lisp systems that 
Dick benchmarked, and will no doubt be as difficult to summarize 
succinctly as any other such system.

The serious question, however, is that of trying to relate micReceived: from Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA09043; Tue, 7 Nov 89 13:57:24 -0800
Received: from Chardonnay.ms by ArpaGateway.ms ; 07 NOV 89 13:58:11 PST
Return-Path: <komar@gudusa.enet.dec.com>
Redistributed: CommonLoops.pa
Received: from decwrl.dec.com ([16.1.0.1]) by Xerox.COM ; 07 NOV 89
 13:53:09 PST
Received: by decwrl.dec.com; id AA02008; Tue, 7 Nov 89 13:51:49 -0800
Date: Tue, 7 Nov 89 13:51:42 -0800
Message-Id: <8911072151.AA02008@decwrl.dec.com>
From: komar@gudusa.enet.dec.com (Is Eternal Vigilance the price of Liberty?
 07-Nov-1989 1651)
To: "CommonLoops.pa@xerox.com"@decwrl.dec.com
Subject: Found my bug, and here's a small example that shows PCL's bug.



	Gregor says about the error in DCODE-CACHE-MISS
	`<some-object> is not a number.' :

From:	GUDUSA::DECWRL::"Gregor.pa@Xerox.COM"  3-NOV-1989 00:27:29.99

I heard about this problem once, as I recall it may be because either:

  you have methods with non-congruent lambda lists

	<pk:> I applied the check-lambda-list-congruency patch (though
	<pk:> I didn't test it)  It didn't complain when I recompiled
	<pk:> my program.

or

  you are calling a generic function with too few required arguments (or
  maybe it was too many).

	<pk:> That was the problem!  I was invoking a method with
	<pk:> one parameter, but the method required two parameters.
	<pk:> (Big sigh)

Both of these are just guesses.  Sorry but I am not maintaining that
version of PCL anymore.  I am working on a new one which doesn't even
have a function by that name.

	<pk:> I eagerly await the next public version.

		Paul Komar.

	P.S. Here is a small example that demostrates the problem:
	(It is so much easier to find a small example of a problem,
	 when you know what the problem is :-)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;;        Title : too-few-params.lsp
;;;
;;;  Last Edited : Tue Nov  7 11:33:57 1989
;;;
;;;  Description : 
;;;                
;;;    Defs : 
;;;			try
;;;	[method]	foo
;;;	defclass	bar
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


(use-package 'pcl)


(defclass bar
    ()
  (
   (a :initarg :A :initform "A" :accessor bar-a)
   )
  )

(defmethod foo ((b bar) other)
  )


(defun try ()
  (setf bar (make-instance 'bar))
  (foo baR)
  )

#|

Causes this output:
Dribbling to CLU3:[KOMAR.LISP.PCL]ERROR.OUT;1
Lisp> (try)

Error in Pcl::Dcode-Cache-Miss:
Argument must be a number:
#<Compiled Function Pcl::Notice-Methods-Change-2 #x4BA35>

Control Stack Debugger
Apply #6: (Try) 
Debug 1> 
Lisp> (dribble)

|#