Re: Elisp performance

[Daniel Kraft]

Ken Raeburn wrote:
> > Obviously, it would help a lot to do so.  On the other hand, switching 
> > to primitive-ref's would help even more, but I fear we can not easily 
> > do so, because we can not know if a symbol targets a primitive or was 
> > rebound at compile time...  BTW, a quick test with Scheme:
> > [....]
> > So it seems that the Scheme compiler just ignores this possibility... 
> > Is (set! + ...) and expecting (+ 1 2) to change invalid, or should 
> > this strictly be regarded as a bug?
>
> In general I don't think you can assume it for all symbols, but if it 
> helps, the Emacs byte-compiler also assumes that "+" and "cons" and 
> certain other functions won't be redefined.  It's even got an "add1" 
> opcode.
>
> So if I understand right, if you make similar assumptions and change how 
> function bindings are handled, your performance for this code drops to 
> under a second?  It sounds like maybe you can get within shouting 
> distance of Emacs's own performance already, at least for certain test 
> cases.

Well, that's partially true.  For those built-ins that map directly to 
Guile primitives, it would probably be an advantage to build 
make-primitive-ref's for the generated TreeIL code directly; I'm not 
sure if that's done at the moment, but in the future this will help for 
things like optimization and special op-codes (e.g. add1).

I think it would really be reasonable to assume certain symbols don't 
get rebound, if they don't have a different lexical binding at the 
moment; although I think that the concept of dynamic binding is actually 
also about the ability to rebind even built-ins to allow for changes... 
 For instance, what if I wanted to write a program that evaluates the 
"efficiency" of some numerical algorithm by overloading + and * to count 
the number of operations performed?  This seems like a valid need to me 
(in fact, I might be doing something similar for my Bachelor's thesis; 
though probably not in Scheme or elisp, so this does not directly matter 
here).

So my idea was to provide a compiler option to always use an ordinary 
function call for certain or all primitives as a compromise; that sounds 
like a quite good idea to me catering for both needs.

However, as a side-note:  I don't think my code would drop below one 
second if this was implemented (hm, at least I'm not sure), because for 
instance all built-ins returning booleans (like < in the example) can 
not map directly to Guile primitives because I need to translate #f to 
%nil inbetween...  It's a pity because comparisons are probably quite 
common especially in such loops, but if we don't want to get rid of 
translation and don't care about #f in elisp (see my other post in the 
%nil thread), I see no way around this.

> Would this interfere with possibly blending Scheme GOOPS code with Elisp 
> someday?  Or is the generic support there at a lower level than this?  
> (E.g., a "marker" object holds a buffer handle, possibly nil, and an 
> offset that automatically gets adjusted if text is inserted before it.  
> You can use "(+ 1 marker)" and get back an integer one greater than the 
> marker's current offset.  If markers were implemented using GOOPS, would 
> this use of "+" work, given the changes you're suggesting?)

To be honest, I've nearly no idea about GOOPS so far and thus can't 
comment here...

Yours,
Daniel

--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri