Ar an dara lá déag de mí Lúnasa, scríobh Michael Sperber:
Neat - does this cause any slowdown in byte-code execution?
Nothing noticeable; I haven’t measured it, if you have a minute, please do.
(Or suggest a reasonable set of tests test; would hanoi be enough?) This is
the crux of it as a performance issue:
#define IGNORE_MULTIPLE_VALUES(X) (multiple_value_current_limit == 1 ? (X) :
multiple_value_current_limit will be one, most of the time, since most code
is not wrapped with (multiple-value-list ...) or (multiple-value-bind ...),
and that will be the end of the conditional. This is what the assembler
movl multiple_value_current_limit(%rip), %eax
cmpl $1, %eax
An important exception for measuring these things is code executed from
*scratch*, which *is* wrapped in #'multiple-value-list, and so the
IGNORE_MULTIPLE_VALUES actually needs to inspect objects to verify that
they’re not multiple values.
OK, I’ve just taken some time, and profile-expression with (hanoi 6)
repeatedly gives me 10187 ticks (or thereabouts) in both builds. (No change
if I add __builtin_expect in the appropriate place.) This isn’t a great
test, though, it’s dominated by redisplay. Suggestions for a better one?
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
XEmacs-Patches mailing list