Re: Split `simple.el'?

[Paul Eggert <eggert@cs.ucla.edu>]

On 04/04/2018 12:08 PM, Eli Zaretskii wrote:
> Does setting inhibit-compacting-font-caches non-nil changes anything
> in this regard?

Unfortunately, I can no longer run the same test, as this morning I 
changed my desktop configuration drastically (to fix a graphics driver 
freeze -- not an Emacs bug) and I now get quite-different performance 
results. It's a real hassle to change the configuration (it's easy to 
mess up and be left with a complete reinstall as the only real 
alternative) and I'd rather not go back, sorry.

In my new configuration I get different results. If I run:

emacs -Q -eval "(describe-variable 'password-word-equivalents)"

and immediately type C-x C-c to exit, gprof reports the following hot 
spots. Although it is a bit discouraging that so much garbage collection 
is occurring in such a simple use of Emacs, I suspect this is not Drew's 
problem.

Each sample counts as 0.01 seconds.
   %   cumulative   self              self total
  time   seconds   seconds    calls  ms/call  ms/call name
  40.00      0.06     0.06  1424609     0.00     0.00 mark_object
  13.33      0.08     0.02    49803     0.00     0.00 re_search_2
  13.33      0.10     0.02        6     3.33     3.33 sweep_conses
   6.67      0.11     0.01    12632     0.00     0.00 Fmake_string
   6.67      0.12     0.01    11471     0.00     0.00 allocate_vector
   6.67      0.13     0.01     5821     0.00     0.00 bidi_resolve_explicit
   6.67      0.14     0.01     1074     0.01     0.01 font_unparse_xlfd
   6.67      0.15     0.01 deliver_user_signal

> If some of the characters there end up being displayed as squares with
> hex codepoints, i.e. you have no fonts capable of displaying them,
> then this is expected.

The characters are all displayable. I see no squares.

>> We should move password-word-equivalents to an i18n-related file anyway
>> (that is, regardless of Drew's problem), as password-word-equivalents
>> doesn't belong in simple.el.
> That's a separate issue, and will just move the problem from one file
> to another.

Yes, of course.