all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Circular records: how do I best handle them?  (The new correct warning position branch now bootstraps in native compilation!)
Date: Fri, 7 Jan 2022 16:44:40 +0000	[thread overview]
Message-ID: <Ydht+K9TeGALrevN@ACM> (raw)
In-Reply-To: <jwv5yr31ixj.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Sat, Jan 01, 2022 at 12:31:51 -0500, Stefan Monnier wrote:

[ .... ]

> > What I bumped into was circularly linked vectors in the source code
> > being compiled.

> Then my question above turns into: what is this source code?

> > I've amended the reader so that it doesn't put positions on symbols
> > which are read as components of other structures such as byte compiled
> > functions, text property lists in strings, and so on.  (Actually, there
> > was very little to amend.).

> OK.

> >> > The positions get stripped before the code is dumped to the .elc.
> >> Why bother?  You can just have a `print-symbols-without-position` which
> >> you let-bind around the printing code.
> > I think I've got that already, though it's a long time since I looked at
> > it.

> So why do you need to strip the positions before dumping the code into
> the `.elc`?

Thank you very much indeed for this tip.  I don't need to strip the
positions.  eval already handles symbols with position (provided
symbols-with-pos-enabled is non-nil), as does pretty much everything
else, including the native-compiler.

Binding that variable and print-symbols-bare to non-nil rather than
stripping positions was actually quite simple, compared with the mess I
was in trying to deal with the circularity in some of the
lists/vectors/records.  I profiled some of the compilation runs with the
stripping strategy, and garbage collection was consuming around 70% of
the run time.  :-(

I've now got the thing working modulo tidying up.  A make bootstrap now
takes 7min 45sec on my machine, compared with 7min 18sec for the same on
the master branch.  That's a 7% difference.  However, I've still got to
strip out the old warning position mechanism, which should shave
something off of that 7% difference.

[ .... ]

> `put` and `puthash` are just some of the ways a macro's arg can
> "escape".  A macro may also something like

>     (push arg my-list-of-stuff)

> Having to strip symbol positions in `put` and `puthash` (i.e. having
> this implementation detail leak to those places which aren't directly
> related to compilation) is pretty ugly.  Do we really want to extend
> that to `setq`, `aset`, and whatnot?

No.  What we have to do is NOT to strip positions off of these objects,
instead warning users to be careful about saving bits of code in a way
that survives the byte compilation.  Possibly we should give them the
position stripping function to use at their discretion.  What do you
think?

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



      reply	other threads:[~2022-01-07 16:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-23 21:15 Circular records: how do I best handle them? (The new correct warning position branch now bootstraps in native compilation!) Alan Mackenzie
2021-12-24 13:56 ` Stefan Monnier
2021-12-24 20:37   ` Alan Mackenzie
2021-12-26 20:35     ` Stefan Monnier
2021-12-30 16:49       ` Alan Mackenzie
2021-12-30 18:37         ` Stefan Monnier
2021-12-31 21:53           ` Alan Mackenzie
2022-01-01 17:31             ` Stefan Monnier
2022-01-07 16:44               ` Alan Mackenzie [this message]

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=Ydht+K9TeGALrevN@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.