Re: Beware of modules.
On Thu, Jan 14, 1999 at 06:17:47PM -0800, J. Kean Johnston wrote:
On Fri, Jan 15, 1999 at 01:18:37AM +0100, Olivier Galibert wrote:
> 2- What we're talking about is function call (trampoline or indirect)
> vs. _inline_. The 30% slowdown of mule is mostly due to the fact that
> moving to the surrouding characters is more complex than p++ and p--,
> and you would want to change that to a _function_call_ ?
Not at all ... MULE was stated as a POSSIBILITY, and there are obvious
reasons why that should be discounted. Something as fundamental as
MULE or MINIMAL_TAGBITS can not, of course, be modulized.
Ok. Now it starts to be more reasonable. Things that are already
indirect function calls wouldn't suffer. The objection against PIC
code speed still holds, though.
> A lot of people are installing both the MULE and non-MULE
version of
> xemacs on the same system. MULE and non-MULE modules won't be
> compatible at all.
The obious solution is to have two architecture directories, one for
MULE and one without. They will have to keep two versions of ellcc around
for the module compiler too, since it is installed in $(bindir) not into
$(archlibdir).
Mule isn't the only distinction, it's only one of the worst. For a
long time to come you will have a huge dependency for a module to the
executable it was compiled with.
oh you meant unEXECing. The terminolgy you used confused me. What
you
really mean is dumping, or unexecing. undumping is a double-take :-)
Sorry :-) English isn't my native language.
However, most of the pre-loaded stuff is supposed to be RELATIVELY
autonomous
isn't it?
I'm afraid not. Look at lisp/dumped-lisp.el.
This is the conceptual procedure, not an exact description. This is
the case
on SVR3.2 and later. Is it THAT much less efficient in other environments?
I think it is quite exact, and similar than in other environments.
It's at best not much slower than the monolithic version.
My gripe against your idea of breaking in modules is that for now most
of your arguments are technically wrong. For instance:
This gives users choices they didnt have before (eg, I think I'll
try
loading the Lucid widgets instead of the mOtif ones) and it reduces the
size of the in-memory footprint of Emacs considerably.
The part about flexibility may be true, although I wonder about the
cost. The part about the in-memory footprint is simply wrong. I can
only hope that you're not one of those that can't understand the
difference about real and virtual memory usage. We're talking about
real oses here.
I dont buy the argument that everything that is unused is swapped
either.
Most systems have limited swap space, and why waste 20MB in swap if we
only need to waste 5? Why have hundreds of extra shared pages when we really
only need a few?
Like I said, everything unused is not loaded at all with all decent
VMs.
Emacs used to be a 700K binary. Now its a 2.6MB image and thats
excluding
all of the shared libraries that it loads. We CAN stop this excess.
Maybe, but not by making a bunch of modules which are going to add to
the size of the executable itself.
Actually, I'm not necessarily againt this module thingy. I just don't
see, for now, what we would gain, except from a _lot_ of bugs to cope
with and the freezing of internal interfaces we'd rather want to keep
changeable at will for now.
OG.