all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Andreas Röhler" <andreas.roehler@online.de>
Cc: 14518@debbugs.gnu.org
Subject: bug#14518: C and Emacs Lisp code parts
Date: Wed, 06 Jul 2016 17:52:54 +0300	[thread overview]
Message-ID: <83shvmn7i1.fsf@gnu.org> (raw)
In-Reply-To: <fc7419b6-3544-3204-357f-2739a83669d5@online.de> (message from Andreas Röhler on Wed, 6 Jul 2016 09:25:54 +0200)

[Please don't cross-post between the bug list and emacs-deve.]

> From: Andreas Röhler <andreas.roehler@online.de>
> Date: Wed, 6 Jul 2016 09:25:54 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> abbrev--describe               36050       15.224345396 0.0004223119
> abbrev-edit-save-buffer        1           8.034011581   8.034011581
> abbrev-edit-save-to-file       1           8.033998314   8.033998314
> abbrev--write                  18025       5.8414600190 0.0003240754
> define-abbrevs                 1           1.334075568   1.334075568
> abbrev-get                     107835      0.5151135200 4.776...e-06
> abbrev-table-get               36964       0.1173239610 3.174...e-06
> abbrev-table-put               18320       0.0690998279 3.771...e-06
> abbrev-table-empty-p           584         0.010703864 1.832...e-05
> abbrev-table-p                 584         0.0050513859 8.649...e-06
> abbreviate-file-name           91          0.002899625 3.186...e-05
> abbrev-table-name              2           0.000254252   0.000127126
> abbrev-mode                    1           1.4463e-05    1.4463e-05

Thanks.

It is better to use profiler.el, because it doesn't change the code
being profiled, and also can profile primitives.  If you can produce a
profile using profiler.el, and present it in fully expanded form,
please do.

Also, I'm not sure how to read the above (and the elp documentation
doesn't really help).  What was the total elapsed time it took to run
this scenario?  Is it the sum of all the numbers in the first column,
i.e. about 37 sec?  Or does the elapsed time for each function include
all of its callers?  Either way, the numbers look strange: why did it
take abbrev-edit-save-to-file, whose body is almost empty, 8 sec,
whereas abbrev--describe took 15 sec?  What am I missing?

Anyway, I looked at the v22 C implementation of the relevant
functions, and I see that the Lisp implementation is essentially
identical to C.  For example, here's the Lisp implementation of
abbrev--describe:

  (defun abbrev--describe (sym)
    (when (symbol-value sym)
      (prin1 (symbol-name sym))
      (if (null (abbrev-get sym :system))
	  (indent-to 15 1)
	(insert " (sys)")
	(indent-to 20 1))
      (prin1 (abbrev-get sym :count))
      (indent-to 20 1)
      (prin1 (symbol-value sym))
      (when (symbol-function sym)
	(indent-to 45 1)
	(prin1 (symbol-function sym)))
      (terpri)))

and here's what we had in Emacs 22:

  static void
  describe_abbrev (sym, stream)
       Lisp_Object sym, stream;
  {
    Lisp_Object one, count, system_flag;

    if (INTEGERP (XSYMBOL (sym)->plist))
      {
	count = XSYMBOL (sym)->plist;
	system_flag = Qnil;
      }
    else
      {
	count = Fget (sym, Qcount);
	system_flag = Fget (sym, Qsystem_type);
      }

    if (NILP (SYMBOL_VALUE (sym)))
      return;

    one = make_number (1);
    Fprin1 (Fsymbol_name (sym), stream);

    if (!NILP (system_flag))
      {
	insert_string (" (sys)");
	Findent_to (make_number (20), one);
      }
    else
      Findent_to (make_number (15), one);

    Fprin1 (count, stream);
    Findent_to (make_number (20), one);
    Fprin1 (SYMBOL_VALUE (sym), stream);
    if (!NILP (XSYMBOL (sym)->function))
      {
	Findent_to (make_number (45), one);
	Fprin1 (XSYMBOL (sym)->function, stream);
      }
    Fterpri (stream);
  }

As you see, both versions call the same primitives and do little
else.

I see the same basic picture with all the functions which are hot
spots according to the elp profile.  So if indeed the Lisp version is
significantly slower, the only way I can explain that is that we have
some very basic inefficiency in the byte-code interpreter, something
that, if true, is completely unrelated to abbrev.el itself.

So please do the same as you did here with Emacs 22.3, and with the
same abbrevs list, and tell how much elapsed time this takes on the
same system.  We should anyway analyze this comparatively, not in
absolute terms.  (Alternatively, post here the list of the abbrevs you
used in your experiment, then others could do these measurements,
compare them, and maybe provide more information/investigate deeper.)

Thanks.





  parent reply	other threads:[~2016-07-06 14:52 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01  8:03 C and Emacs Lisp code parts Andreas Röhler
2016-07-01  8:13 ` Eli Zaretskii
2016-07-01  8:39   ` Andreas Röhler
2016-07-01  9:16     ` Alan Mackenzie
2016-07-01 12:07       ` Andreas Röhler
2016-07-01 13:04         ` Eli Zaretskii
2016-07-05 22:48           ` John Wiegley
2016-07-06  7:25             ` bug#14518: " Andreas Röhler
2016-07-06  7:25             ` Andreas Röhler
2016-07-06  7:31               ` Andreas Röhler
2016-07-06 14:01               ` bug#14518: " Noam Postavsky
2016-07-06 14:52               ` Eli Zaretskii [this message]
2013-05-31  9:30                 ` bug#14518: abbrev edits - delay when saving Andreas Röhler
2013-06-01  3:01                   ` Leo Liu
2013-06-01  5:52                     ` Andreas Röhler
2013-06-05 10:11                     ` Andreas Röhler
2013-06-05 13:12                       ` Stefan Monnier
2013-06-05 17:02                         ` Glenn Morris
2013-06-05 17:20                           ` Andreas Röhler
2013-06-07  1:43                           ` Glenn Morris
2013-06-07  5:38                             ` Andreas Röhler
2013-06-07  7:13                               ` Glenn Morris
2013-06-07  7:41                                 ` Andreas Röhler
2016-07-06 15:44                   ` bug#14518: C and Emacs Lisp code parts Glenn Morris
2016-07-06 16:15                     ` Eli Zaretskii
2016-07-06 22:36                       ` John Wiegley
2016-07-07  7:33                         ` Andreas Röhler
2016-07-07 15:16                           ` Eli Zaretskii
2016-07-06 16:21                     ` Andreas Röhler
2016-07-06 16:37                       ` Eli Zaretskii
2016-07-06 17:27                         ` Andreas Röhler
2016-07-06 17:35                           ` Eli Zaretskii
2016-08-05 23:38                   ` bug#14518: Status: abbrev edits - delay when saving npostavs
2016-12-07 19:56                     ` Glenn Morris
2016-07-06 15:27               ` bug#14518: C and Emacs Lisp code parts Phillip Lord
2016-07-06 15:27               ` Phillip Lord
2016-07-01  9:17     ` John Wiegley
2016-07-01 13:26       ` Andreas Röhler
2016-07-01  9:25     ` Eli Zaretskii
2016-07-01 12:25       ` Andreas Röhler
2016-07-01 13:01         ` Eli Zaretskii
2016-07-01 13:05         ` Andy Moreton
2016-07-01 15:14           ` Karl Fogel
2016-07-01 16:52             ` Andreas Röhler
2016-07-01 17:13               ` Eli Zaretskii
2016-07-01 17:36                 ` Andreas Röhler
2016-07-01 17:38                   ` Eli Zaretskii
2016-07-02 16:41                     ` Fabrice Popineau
2016-07-02 17:16                       ` Eli Zaretskii
2016-07-01 17:55                   ` Alan Mackenzie
2016-07-01 18:31                     ` Andreas Röhler
2016-07-01 18:57                       ` Alan Mackenzie
2016-07-01 20:04                         ` Andreas Röhler
2016-07-01 20:31                           ` Davis Herring
2016-07-02  6:34                             ` Andreas Röhler
2016-07-02 11:29                               ` Paul Eggert
2016-07-05 17:02                               ` Davis Herring
2016-07-05 19:35                                 ` Andreas Röhler
2016-07-02  6:32                           ` Eli Zaretskii
2016-07-02  7:01                             ` Andreas Röhler
2016-07-02  8:15                               ` Eli Zaretskii
2016-07-02  3:32 ` Tom Tromey
2016-07-02  3:42   ` Clément Pit--Claudel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83shvmn7i1.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=14518@debbugs.gnu.org \
    --cc=andreas.roehler@online.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.