Re: Should we just start dumping cl-lib?

[Daniel Colascione]

On 10/03/2015 12:22 AM, Eli Zaretskii wrote:
>> From: Daniel Colascione <address@hidden>
>> Date: Fri, 2 Oct 2015 17:19:45 -0700
>>
>> On 10/02/2015 09:07 AM, John Wiegley wrote:
>>>>>>>> Eli Zaretskii <address@hidden> writes:
>>>
>>>> Please always accompany such suggestions with rationale. Adding to the core
>>>> just because "why not?" is IMO not a good methodology. Some people still
>>>> care about the memory footprint of programs, so we don't want to bloat that
>>>> unless there are good reasons. Such reasons can only be discussed on a case
>>>> by case basis.
>>>
>>> Although personally I wouldn't mind seeing cl-lib in core, for the benefit 
>>> of
>>> Emacs I have to agree with Eli. It's not something we should do just because
>>> it sounds like a good idea, but because not doing it would cost us 
>>> something.
>>> Shaving a few milliseconds from startup is not enough of a gain to be worth
>>> bloating core.
>>
>> What's the cost of increasing the size of the dumped image? We don't
>> take COW faults on most of the pages, so we can discard them at will.
>> Because the OS can discard clean pages without writing them to the
>> pagefile and reconstitute them at will, transferring code from Emacs
>> private allocations to the dumped Emacs image _decreases_ memory
>> footprint. That we also shave a few milliseconds off startup is another
>> benefit.
>>
>> If not cl-lib, then what? What is the actual bar?
> 
> Did you miss my further message where I said we should probably
> preload cl-lib, because many popular commands in a fresh session load
> it anyway?

I did, sorry. Anyway, let's wait until we have a new maintainer and
release Emacs 25 before making this change, but it sounds like we
definitely want to proceed in the direction of dumping cl-lib.

Trying to do it locally, I ran into a very weird problem: functions we
call at compile time, like cl--defalias, raise errors when called:  the
bytecode vector ends up being the number zero instead of the expected
string. Turning cl--defalias and similar functions into macros makes the
build work, but it doesn't solve the real problem.

signature.asc
Description: OpenPGP digital signature