Hi,
In the version found in
http://srfi.schemers.org/srfi-45/post-mail-archive/msg00010.html  the slow down
does not occur.
I ran all leak and reentrancy tests on Phil's code with MzScheme and with the
version mentioned above they run well and in bound space (except in some cases
on times3 using MzScheme) I do have versions of procedure force that has no
problems with times3 under MzScheme. See problem report 8881. Also see 8963)
When testing Phil's code for reentrancy and leaks I define:

(define-syntax lazy (syntax-rules () ((_ expr) ((stream-lambda () (stream-cons
expr stream-null))))))
(define (force strm) (stream-car strm))

Jos

((((lambda(x)((((((x x)x)x)x)x)x))
   (lambda(x)(lambda(y)(x(x y)))))
  (lambda(x)(write x)x))
 'greeting)

----- Original Message -----
>From: "AndrevanTonder" <xxxxxx@het.brown.edu>
To: "Eli Barzilay" <xxxxxx@barzilay.org>
Cc: "Jos Koot" <xxxxxx@telefonica.net>; "Phil Bewig" <xxxxxx@gmail.com>;
<srfi-45@srfi.schemers.org>
Sent: Tuesday, November 13, 2007 4:54 PM
Subject: Re: simpler srfi 45 implementation

> On Tue, 13 Nov 2007, Eli Barzilay wrote:
>
>> I was aware of the possible optimization at the time, but didn't find
>> any example where it mattered.  However, if you do put it in:
>>
>>>             [(promise? p)
>>>              (let* ((v (force p)))
>>>               (if (not (pair? (promise-p prom)))
>>>                   (set-promise-p! prom (list v)))
>>>               (car (promise-p prom)))]
>>
>> then you do the recursive forcing of `p' in a non-tail conext.  My
>> (vague, not formal at all) feeling about these "referral promises" is
>> that they do happen in places where the original code had a tail call,
>> so it might be a bad idea to break it.
>
> The suggested optimization looks very suspicious also to me.
> It seems that the non-tail-call could break space-safety.
>
> Two questions:
>
>  - Have you run the SRFI-45 tests on your suggested optimization?
>    Note that this involves uncommenting the mostly nonterminating
>    test cases, letting them run for some time, keeping track
>    of the memory consumption with some other tool, and verifying
>    that it stays bounded.  Of course, this is not a substitute
>    for a theoretical analysis, but it should show pretty quickly
>    if you are not on the right track.
>
>  - Did you find the same slowdown for the first implementation
>    given in the message
>    http://srfi.schemers.org/srfi-45/post-mail-archive/msg00010.html ?
>    (That one is easier for me to understand and comment on - Eli's
>    I would have to study again).
>
> Cheers
> Andre
>