sig segv cut-n-paste issue with 10^6 lines

[Stephen J. Turnbull]

Vladimir G. Ivanovic writes:

 > Is there somewhere I could find out more about the differences between 
 > the FSF and XEmacs byte compilers

Yes.  In the source code.

 > and (hopefully) the reasons for those differences? (Google was
 > unhelpful and I didn't see anything in the byte-*.el files.)

The reason for the difference is historical and legal.  In 1997-1998
XEmacs added Mule which required some changes, and also did a lot of
work on optimizing the byte compiler.  Martin Buchholz offered to port
the XEmacs improvements to GNU Emacs (AFAIK copyright is assigned to
the FSF) around 1999 when he was at ETL, but was turned down because
of the Great Redisplay Rewrite; Gerd didn't have time.

Since then GNU has added a very divergent version of Mule and done its
own optimizing.  AFAIK they never contacted Martin, and of course it's
very possible that the offer to do the work was no longer open.
Without Martin's personal involvement to testify that the code was not
polluted with unassigned code, it's unlikely that the FSF lawyers
would permit the XEmacs code into GNU Emacs.

Of course we could port GNU improvements in the other direction, but
we have a working, reasonably well-optimized byte compiler and
interpreter.  In fact, as of Python 2.0 I think it was, the XEmacs
byte code was about 10% faster on a meaningless benchmark than
Python's VM.  But actually there is meaning there: there probably is
very little efficiency improvement that can be squeezed out of the
XEmacs virtual machine without changing Emacs Lisp.

There are also a fair number of minor differences in philosophy, which
you will find oblique references to in comments in the bytecode system
implementation.

All this could be worked out, I suppose, but what is the gain to be
expected from that?