Re: Help with eql specializers

[kanderso@DINO.BBN.COM]

  Date: Sun, 23 Jul 89 21:43:57 CDT
  From: Daniel A Haug <aihaug@austin.lockheed.com>
  Message-Id: <8907240243.AA14221@shrike.Austin.Lockheed.COM>
  To: commonloops.pa@xerox.com
  Subject: Help with eql specializers
  Cc: haug@austin.lockheed.com
  
  I've hit upon a major performance problem with PCL, and I don't know what
  caused it.  The only thing I know for sure is that it happened when I
  began using eql specializers on a certain generic function.  My typical
  runtime on this function jumped from around .03 seconds to about 6 seconds.
  
  I ran the symbolics Metering Interface over the form, and found that
  almost all of the time is spent in PCL:NOTICE-METHODS-CHANGE-1.  Inside
  of NOTICE-METHODS-CHANGE-1, the run-time is split between
  COMPUTE-COMBINED-METHODS and UPDATE-DISCRIMINATOR-CODE of STANDARD-GENERIC-
  FUNCTION.  In fact, I placed a break loop in NOTICE-METHODS-CHANGE-1, and
  saw that it was getting called a zillion (excuse me) times.
  
Can you extract a short example we can play with?  Off hand, i'd say
that notice-methods-change... is only called when a generic function
is invalidated.  It turns out that lots of unnecessary invalidation
occurs when classes are defined.  However, i'm suprised that this
happens when everything is loaded, and you are running a program.

  SHould I be avoiding EQL specializers?  Can I expect to always pay this
  kind of performance penalty for using them?  Or is there a problem?  The
  generic function in question here as a total of four methods defined on
  it, three of which have EQL specializers.

Eql specializers were not optimized well in the previous PCL's, and
i'm not sure what happens now.  
  
  Any help is really appreciated.  I'm going nuts over this, because it
  is tied in with menu clicks, and my users are waiting over 6 seconds now
  between clicking on a window, and getting a response.
  
  dan haug
  Internet: haug@austin.lockheed.com
  UUCP:     ut-emx!lad-shrike!aihaug