unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Rocky Bernstein <rocky@gnu.org>
Cc: Alan Mackenzie <acm@muc.de>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects]
Date: Thu, 19 Mar 2020 18:05:33 -0400	[thread overview]
Message-ID: <jwv1rpoja1t.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CANCp2ga-7bpRJ+7chvxv4QkmG-zpWmdtmRVNuZtm920vsDHQ9Q@mail.gmail.com> (Rocky Bernstein's message of "Thu, 19 Mar 2020 16:56:45 -0400")

>> "More precise line numbers" is a misconstruction, even though I've used
>> such language myself in the past.  Line numbers don't come from a
>> physical instrument which measures with, say +-1% accuracy.  CORRECT
>> line (and column) numbers are what we need.
> A bytecode offset is exact and accurate.

I think he was talking about line-number info in byte-compiler warnings
(where the info comes from the source code, not from the backtrace).
Currently we use a hack that gives us approximate locations which can be
wildly off-the-mark.

> Right now this information unavailable. I think the interpreter uses
> C pointers stored in a register.  So just recording the bytecode
> offset is a little bit of a slowdown, but not that much.

Indeed.  If it's too high we could make it conditional on a boolean
variable.

> I doubt it would even register as %1 slower.

Reminds me that another project could be to try and speed up function
calls.  The difficulty here is that we don't really know what's the main
source of the cost, so there's a good chance that any specific attempt
will give disappointing results.  It'd still be useful in helping us
getting a better idea of what it is that takes time.

> But just that would open the way for improvements. This is doable by a
> Summer student - Stefan thinks it trivial.

Just recording this info in the backtrace (at a minor performance cost)
is indeed very easy.

> But tas you point out there is overhead in getting it accepted and
> into GNU Emacs.

Right.  Until this info is actually usable by tools like the debugger,
the code would inevitably be #ifdef'd out unless it has zero-cost which
seems unlikely.

> Having access to the bytecode offset in a traceback there next are
> several options.  At the lowest level there is just showing that along
> with a disassembly of the bytecode.
> And that I believe that is also doable by a summer student.

Agreed.


        Stefan




  reply	other threads:[~2020-03-19 22:05 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 15:10 GNU is looking for Google Summer of Code Projects Rocky Bernstein
2020-03-19 17:35 ` Stefan Monnier
2020-03-19 17:56   ` Andrea Corallo
2020-03-19 18:05     ` Andrea Corallo
2020-03-19 18:19     ` Rocky Bernstein
2020-03-19 21:26     ` Stefan Monnier
2020-03-19 21:45       ` Andrea Corallo
2020-03-19 23:07         ` Rocky Bernstein
2020-03-19 20:34   ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Alan Mackenzie
2020-03-19 20:43     ` Andrea Corallo
2020-03-20 19:18       ` Alan Mackenzie
2020-03-21 11:22         ` Andrea Corallo
2020-03-21 15:30           ` Correct line/column numbers in byte compiler messages Alan Mackenzie
2020-03-21 16:28             ` Andrea Corallo
2020-03-21 18:37               ` Andrea Corallo
2020-03-21 20:19                 ` Alan Mackenzie
2020-03-21 21:08                   ` Andrea Corallo
2020-03-21 23:39                     ` Andrea Corallo
2020-03-22 11:26                   ` Alan Mackenzie
2020-03-19 20:56     ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Rocky Bernstein
2020-03-19 22:05       ` Stefan Monnier [this message]
2020-03-20 19:25       ` Alan Mackenzie
2020-03-19 21:41     ` Stefan Monnier
2020-03-19 22:09       ` Stefan Monnier
2020-03-20 20:10       ` Alan Mackenzie
2020-03-20 21:23         ` Rocky Bernstein
2020-03-20 21:27         ` Clément Pit-Claudel
2020-03-20 23:46           ` Stefan Monnier
2020-03-20 21:30         ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=jwv1rpoja1t.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=rocky@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).