emacs-devel
[Top][All Lists]
Advanced

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

Re: [ELPA] Update package: psgml: handle (compile-internal) obsoletion


From: Stefan Monnier
Subject: Re: [ELPA] Update package: psgml: handle (compile-internal) obsoletion
Date: Thu, 18 May 2017 09:04:22 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

> It looks like (compile-internal) has been deleted, finally.  This patch
> (see attached) adds a check to use the new (compilation-start) while
> still being compatible with really old versions.

Thanks, installed into elpa.git (but without the check: this version of
Psgml doesn't work in such old Emacs versions anyway).

> My computer ships with v22,

Well, personally, I don't consider that Emacs is distributed
with MacOSX.  They include some crippled tty-only version of it,
probably for sysdmin purposes.

>  I'm not very familiar with Emacs' dynamic loader.  Does it optimize
>  out the branch instruction on load since it's a comparison of a
>  constant?

Actually, it's not a constant: it's a variable which will probably
never be modified.

>  or does compiled code get interpreted literally?

It's pretty much interpreted literally.

>  It's only a quick branch and calling the external procedure takes
>  much longer, but I used the version check instead of (fboundp) since
>  it's probably faster than the obarray lookup if the check is
>  performed every time you call the procedure.

fboundp doesn't do an obarray lookup.  It already has the symbol so it's
only an field access within the symbol object.  It might very well be
faster than your < test (but I won't go and test it because I'm pretty
sure it's 100% lost in the noise, anyway).


        Stefan




reply via email to

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