emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Skipping unexec via a big .elc file


From: Daniel Colascione
Subject: Re: Skipping unexec via a big .elc file
Date: Sun, 30 Oct 2016 09:52:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/30/2016 07:43 AM, Ken Raeburn wrote:

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

Awesome! Even if we go for something besides a big elc file for startup, these improvements will help.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]