[plt-dev] Re: Fine-tuning performance

From: Carl Eastlund (cce at ccs.neu.edu)
Date: Fri Jan 29 12:38:39 EST 2010

Matthew, I hope you get this via plt-dev; two attempts to send it
directly to you have failed.  Here's the message Google gives me (I
sent these as cce at ccs.neu.edu, using my carl.eastlund at gmail.com
account):

--------------------------------------------------

Delivery to the following recipient failed permanently:

    mflatt at cs.utah.edu

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.7.1 Client host rejected: cannot
find your reverse hostname, [74.125.82.46] (state 14).

--------------------------------------------------

I've had one other message bounce like this recently, although in that
case a second attempt worked.  The response suggests "contacting the
other email provider"; if there's an appropriate person at Utah you
could pass this on to (or that I should), I'd appreciate it.

Carl Eastlund

On Fri, Jan 29, 2010 at 12:27 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> I have some performance related questions about the PLT runtime.
> These are mostly for Matthew, but I'm posting this to plt-dev in case
> anyone else is interested in the answers, or can supply one.
>
> One, there are some functions that I memoize with a weak hash table.
> Are there any sorts of values that will never be collected, and will
> persist forever in the hash table?  For instance, do word-sized values
> like fixnums or ASCII characters stick around?
>
> Two, I've gotten the impression that special casing variable-arity
> functions at some fixed arities via case-lambda will speed up the
> common case.  Is this true, and if so how significant is the
> difference (as a general order of magnitude)?  Is there some cutoff
> past which this specialization no longer pays off?  I know there's no
> a priori precise answer, I'd have to experiment for that, but if
> there's a representation change (e.g. functions calls with more than 8
> arguments get allocated as lists regardless) it would be useful to
> know.
>
> Thanks for any help.
>
> Carl Eastlund


Posted on the dev mailing list.