[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

&rest [discussion] replacement/addition

    Date: Fri, 8 Apr 88 18:29 EDT
    From: Barry Margolin <barmar@Think.COM>

    I noticed you didn't try the following version.  This is identical to
    the version you included in your message, except that it takes the
    previous words as a single argument rather than as an &REST argument.
    One definite advantage of this version is that it won't exceed
    CALL-ARGUMENTS-LIMIT if it recurses deeply.

I had run this version before, but neglected to include it in the timing

input string	code version		runtime (sec)	list consing (words)
hi there	no &rest, cons		14.25		1280

ian gooch	no &rest, cons		138.3		4626


    Date: Sat, 9 Apr 88 12:35 EDT
    From: ELIOT%cs.umass.edu@RELAY.CS.NET

	...I think &rest should always have a form which allows
       its user to control consing, regardless of how performance might or
       might not be affected.

    After ALL the discussion about this topic, it seems that this claim should
    be justified, if it is going to be made at all.  I think there is general
    agreement that the only reason why the user might need control over consing
    &rest lists is the effect on performance.

You're right.  I guess I didn't mean that the way it came out.
Performance is the object, but my current assumption is that consing
must adversely affect overall performance. 

	Your data does not seem
    to show such an effect.  Another experiment you could try would be to
    run the same examples many times (100 or 1000 times) with the
    garbage collector on.  The idea is to do so much consing that the GC must
    run.  That way you can claim that the timings include the GC overhead.

Good idea.  Results later.

    If you do that and still get practically the same runtime results for all
    of the different versions, then I think you should conclude that the runtime
    of your example does not depend upon how the &rest list is handled.

  -- William D. Gooch