[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
runs.
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