[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Skipping unexec via a big .elc file
From: |
Ken Raeburn |
Subject: |
Re: Skipping unexec via a big .elc file |
Date: |
Sun, 30 Oct 2016 10:43:31 -0400 |
I wrote:
> Patched substitute_object_recurse after the check for the subtree matching
> the placeholder, so that if the subtree passed was a symbol or number, it
> would simply be returned without consulting seen_list or read_objects. Run
> time is now 0.7s; Fassq is a bit over 50% of that, and Frassq about 17%, and
> _IO_getc around 11%. I think it should be safe to short-circuit it for some
> other types as well.
>
> I had my getc_unlocked change sitting around so I pulled that in. Run time
> is now 0.6s, with Fassq at 57% and Frassq at 18%.
>
> Next on the profiling chart is oblookup, but it’s only at 4% so I’m going to
> ignore OBARRAY_SIZE for now. However, OBARRAY_SIZE could affect the order of
> atoms in processing, which could drastically rearrange the ordering of the
> data structures in dumped.elc.
>
> I think the next step is to look at replacing read_objects, probably with a
> pair of hash tables, but it’s getting a bit late for trying that tonight.
I switched over to a pair of hash tables and the run time is just under 0.2s on
my test machine now. Profiling reports are now topped by read1, readchar, and
readbyte_from_file (now including the expanded getc_unlocked calls), accounting
for about 30% of the CPU time between them. The hash functions and
substitute_object_recurse are not taking a significant amount of time.
I took a look at the types of shared data in one of the generated dumped.elc
files I got; almost 2700 were strings (all without text properties), almost
1900 were cons cells, and the rest numbered under 300. So I’m not sure
special-casing other types besides Lisp_Cons in read1 will gain us much.
It took me a while to sort through the lookups being done during and after
parsing of an object and how the checks for circular objects work, but I think
I’ve got it working. I’ve pushed a scratch branch over with the changes if
you’d like to try them, though I think I botched the git push syntax when
trying to create “scratch/raeburn/startup” somehow, so I created
“scratch/raeburn-startup”… or possibly I’ve created both? I saw an email
notification go out for both, but I only see the latter in the repository
browser interface…
Ken
- Re: Skipping unexec via a big .elc file, (continued)
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2016/10/24
- Re: Skipping unexec via a big .elc file, Perry E. Metzger, 2016/10/25
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2016/10/24
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/24
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2016/10/25
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/25
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2016/10/27
- Re: Skipping unexec via a big .elc file,
Ken Raeburn <=
- Re: Skipping unexec via a big .elc file, Simon Leinen, 2016/10/30
- Re: Skipping unexec via a big .elc file, Daniel Colascione, 2016/10/30
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/31
- Re: Skipping unexec via a big .elc file, Lars Brinkhoff, 2016/10/24
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2016/10/24
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/23
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/23
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/23
- Re: When should ralloc.c be used?, Stefan Monnier, 2016/10/23
- Re: When should ralloc.c be used?, Eli Zaretskii, 2016/10/23