[Top][All Lists]

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

Re: When should ralloc.c be used? (WAS: bug#24358)

From: Richard Stallman
Subject: Re: When should ralloc.c be used? (WAS: bug#24358)
Date: Fri, 28 Oct 2016 15:12:27 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The Lisp approach has a huge advantage: it is much simpler, so
  > everyone here will understand it, and it is much easier to maintain
  > and develop.

The special format I propose is simple enough.

  > So if the performance hit is bearable (meaning will be accepted by the
  > crowd), it should IMO be preferred for reasons of project management
  > and its future,

Slowness here affects every user and is quite noticeable.
Don't we already know that Lisp is too slow for this?

It is worth substantial extra effort to speed this up.

  > care about the future of Emacs in the face of the fact that fewer and
  > fewer people know, or even want to know, about segments and offsets in
  > a binary executable file.

That is an argument for replacing unexec with something that saves the
data to reloed, but it is not an argument for using Lisp as the format.

  >   Using
  > this simple benchmark proposed by Andreas:

  >   time emacs -batch --eval t

I just tried it with my current build (from June).  It took .26 seconds,
which is fast enough.

If replacing unexec with loading Lisp takes .05 seconds more, I won't
complain.  But I think it will take several seconds, if not minutes.

Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

reply via email to

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