[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Circular records: how do I best handle them? (The new correct warni
From: |
Alan Mackenzie |
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 |
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).