Am Freitag, den 01.02.2008, 00:41 -0600 schrieb Zbigniew: > A multiple-value call takes the following route under Chicken: > C_call_with_values -> C_do_apply -> C_values -> values_continuation -> > C_do_apply. A single-value call is compiled to a function call. You > can see why returning a single list value and destructuring it should > be a lot faster. ... > None of this would usually matter because benchmarks are next to > useless. However, one major argument advanced for multiple values > seems to be that the compiler has a chance to optimize them (which > sounds like premature optimization to me, but I digress). So, if > you're going to use multiple values, don't do it because of a > theoretical speedup, but because it semantically fits the problem.
Hm, this makes me wondering. I once was surprised that a large program, when ported from RScheme (which is usually regarded as slow) to chicken, became very slow in comparison. Background: from the internals of rscheme I'd expect multiple value calls to be just as fast there as single value calls. (RScheme maintains a register file, which is used for both arguments and return values.) Now my program heavily uses multiple values, because of both - they fit semantically and are expected to be much faster (there) than consing a list and destructing it again. And I love multiple values. ;-) What I'm wandering about: if the multiple value implementation in chicken is slow, why not change it? A distinguished data type for multiple values some magic (details of which I can't judge about right now) to hide the manual deconstruction. Any opinions? /Jörg _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
