Re: Preview: portable dumper

[Eli Zaretskii]

> From: Daniel Colascione <address@hidden>
> Cc: John Wiegley <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden
> Date: Tue, 29 Nov 2016 10:49:10 -0800
> 
> > Any memory dumper will always be more efficient than loading .elc.
> [...]
> Because you can't possible get away, in the ELC approach, from:
> 
>  1) reading every damn byte of the file, and
>  2) allocating memory for every object you read.
> 
> Efficiency is always going to be at least linear in the size of the
> "elc dump" --- super-linear complexity if you want read-circle.
> 
> A memory dump is linear only in the amount of data you actually
> access. Plus, there's no serialization or deserialization overhead. A
> memory dump is also inherently gentler on the underlying system, since
> we can use many of the pages unmodified (which makes them shareable and
> trivially swappable), while every damn byte of the Emacs heap after
> loading ELC files will be process-private dirty storage.

Like I said: any memory dumper will always be faster.  But having less
functionality coded in non-trivial C is IMO an important goal, one we
have been pursuing for quite some time, and for a good reason.
Although it should be clear that any adequate C implementation will
always be faster than an equivalent Lisp implementation.

> I do not think the portable dumper is something that's so complex as to
> not be worth the performance

It's complex.  I have read the patch.  I do know my way in the Emacs
internals.

> especially since any lread implementation that's even close to being
> acceptably fast is going to be very complex in its own right.

Even if we accept your opinion on the necessity for changes in lread
(and I don't think I agree), that is a one-off job.