On Sep 27, 2005, at 4:43 PM, Caleb Clausen wrote:

> So, it looks like better than 10x as expensive to instantiate and
> extend as to just instantiate. (Some of my measurements showed more
> like 20x.)
>
>

Oh dear.

Thanks for the information Caleb.


> However, I wouldn't worry about the performance of extend unless you
> have good reason to believe it's a bottleneck.
>

Unfortunately in certain cases this will be in a very performance  
sensitive area (I've spent a lot of time profiling it, wouldn't say  
it is as optimal as it can be, but chasing after fractions of a  
percent improvement seems like a waste of time). Fortunately, I can  
identify these and I can probably deal with it differently (i.e.  
build a few classes that extend some of the built in classes -- not  
every class can occur at the critical part). Then in the less  
critical part extend each object as it comes up (likely less time  
critical). Symbols still present a problem (they can't be extended it  
seems).

[As an aside... Here is an example of when a lisp-like macro would  
come in handy. The trouble with symbols is that they are instantiated  
before I can get my hands on them, and Symbol instances cannot be  
extended -- this is a *runtime* issue. In a lisp macro I could scan  
for the symbol definition at *compile* time, not runtime, and  
*before* it is evaluated (i.e. instantiated as a Symbol instance) and  
change the program from a :hello to MySymbol.new("hello") or what- 
ever. Doing work at compile time only affect compilation time not  
execution time, and so can be a very good investment. I suppose I  
could also define a reader-macro and let lisp do the 'scanning' for  
me -- these are applied at read time which is even before compile time.]

----
Bob Hutchison          -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc.  -- <http://www.recursive.ca/>
Raconteur              -- <http://www.raconteur.info/>