emacs-devel
[Top][All Lists]
Advanced

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

Re: return


From: Stefan Monnier
Subject: Re: return
Date: Fri, 03 Dec 2010 17:29:55 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> You mean the performance overhead from adding an extra internal_catch?
>> I doubt there's a free lunch here; adding a "return" or "return-from"
>> mechanism would also add overhead, and that overhead would apply to
>> every single funcall.  Still, it's a worthwhile experiment to implement
>> "return"/"return-from" and see how big the performance impact is.

> I did a quick experiment, and turns out built-in blocking is a little
> faster than an explicit `catch', mostly because of reduced consing.  I
> tested with a function that runs 500,000 tight `while' loops:

>   (defun test-loop-with-catch ()
>     (dotimes (ii 500000)
>       (let ((ll '(1 2 3 4 5 6 7 8 9 10)))
>         (catch 'exit
>         (while ll (setq ll (cdr ll)))))))

> The run time is 1.164s, as opposed to 1.084s with the `catch' omitted.
> So an explicit `catch' adds about 10 percent to the run time.

> If I hack Fwhile to perform a catch internally, the runtime for the test
> function (with the `catch' omitted) is 1.057s, within the margin of
> error of the unhacked Emacs.

A few questions:
- how do you explain that Fwhile with internal catch is faster (1.057 <
  1.084) than without an internal catch?  Or is that what you mean by
  "within the margin of error"?
- You seem to be measuring time for the interpreted code, is that right?
  If so, I think it would be more interesting to measure the time for
  byte-code.

The little tests I've performed seem to indicate that for interpreted
code the extra `catch' doesn't make much of a difference, but for the
compiled version of your test, the difference is around 20%.

> This (very limited) test indicates that adding built-in support for
> block, return, and return-from should have little performance impact.
> (Though the block tags ought to use a specialized obarray instead of
> what cl-macs.el does, which is to intern them as "--cl-block-%s--".)

If we add support for C-like exit statements (break/return, that only
work locally and hence don't add any extra run-time cost) to the
byte-compiler, that would be nice.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]