I patched the startup.el and package.el in the installed emacs. They seems
not work. I'll try to patch the git source prior to the complilation later
when I get time.


1. Even I put the (setq package-enable-at-startup nil) in the top of the
.emacs, it takes 3.692 sec before loading others of the init file. I have a
site-start.el file, which is suposed to run before .emacs is loaded. Woud
it impact the the load process? NB. the 3.692 does not count the site-start
in. It is from
(message ">>> start load .emacs: %.3f sec <<<"
                     (float-time (time-subtract after-init-time
before-init-time)))

2. No mather whether I set package-enable-at-startup, it takes about 8 sec
to load the custom-set-variable. However, it takes only 2.5 sec in the Feb
version.

Symbol's value as variable is void: Info-default-directory-list [14 times]
>>> start load .emacs: 3.692 sec <<<
Loading Sun Shuguang’s .emacs file
>>> before custom-set-variables : 4.176 sec <<<
Loading image-file...done
Loading time...done
Loading completion...done
Loading elec-pair...done
Loading icomplete...done
Loading ido...done
Loading avoid...done
Loading savehist...done
Loading paren...done
>>> custom-set-variables time: 12.387 sec <<<


On Fri, Mar 9, 2018 at 9:35 AM, Noam Postavsky <npostavs@gmail.com> wrote:

> Shuguang Sun <shuguang@gmail.com> writes:
>
> > I built emacs 27 on 4th March, however, the startup gets slower than
> > the build on 4th Feb (which is camparable with the build in https://
> > alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/).
> > I'm sorry I don't know how to repeat it using "-q".
> >
> > System: Windows 7
>
> > Below is the message from 4th March build.
> > 1. It has a warning at the very begining. If start with -q, there
> > will be no such warning.
> > 2. Actually there is nothing before " >>> start load .emacs: 2.575
> > sec <<< ", however, it still takes 2.574 sec.
> > 3. The load time is longer than the 4th Feb build.
> >
> > Symbol's value as variable is void: Info-default-directory-list [14
> > times]
>
> Could you try out the patch posted to emacs-devel?
>
> https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00040.html
>