Re: Preview: portable dumper

[Ken Raeburn]

On Dec 2, 2016, at 09:45, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Stefan Monnier <address@hidden>
>> Cc: address@hidden
>> Date: Fri, 02 Dec 2016 08:04:46 -0500
>> 
>>> Granted, the proposed dumper is not very complicated.  But it isn't
>>> trivial either.  So if we can achieve a similar effect by using the
>>> "normal" loadup code, which is much simpler and doesn't really require
>>> understanding anything new, I think it's more beneficial for the
>>> project's future.
>> 
>> Ken worked on speeding up the lread.c code, and it got to be
>> significantly faster, but not fast enough.  AFAIK it's got to the point
>> where it's not clear exactly how to speed it up further.  Not that it
>> can't be done, but that it's not obvious how, so it's likely going to
>> require some serious rethinking and maybe restructuring/rewrite of
>> the code.
>> 
>> Is it going to happen if we don't merge the pdumper?  I'm not so sure.
> 
> I'm willing to give that a chance.  I don't see any reason to make the
> decision today.
> 
>> The main impetus behind speeding up lread.c is to replace unexec.c, so
>> I agree with you that merging the pdumper might mean that speeding up
>> lread.c will simply never happen.  But I think there's also a very
>> serious risk that even without the pdumper, speeding up lread.c will
>> still never happen: I have no intention on working at speeding up
>> lread.c, AFAICT Ken also gave up on it, anyone else?
> 
> Judging by Ken's response, he didn't give up yet.

No, I just got busy with other things for a bit.

Stefan’s right too… since the current time sinks are the “read” functions 
themselves rather than in support code being called, it’s less immediately 
obvious where work is needed or how to proceed.  And it’s certainly possible 
changes will be needed that aren’t as nicely localized as getc() or recursive 
placeholder substitution.  But, I haven’t tried, yet… :-)

Ken