* Re: master f0b0105: Hoist some byte-code checking out of eval
[not found] ` <20200520062523.3EF4A20AEB@vcs0.savannah.gnu.org>
@ 2020-05-20 12:03 ` Stefan Monnier
2020-05-20 21:21 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-05-20 12:03 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Hoist some byte-code checking out of eval
[...]
> * src/bytecode.c (Fbyte_code): Do sanity check and conditional
> translation to unibyte here instead of each time the function is
> executed.
Hi Paul. I don't understand: AFAIK this function is only used in the
extremely rare case that Elisp does
(byte-code "blabla")
So I think some of the checks you removed from `exec_byte_code` will
simply not be performed any more (at least not on
`byte-code-function-p` objects).
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master f0b0105: Hoist some byte-code checking out of eval
2020-05-20 12:03 ` master f0b0105: Hoist some byte-code checking out of eval Stefan Monnier
@ 2020-05-20 21:21 ` Paul Eggert
2020-05-20 23:21 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2020-05-20 21:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On 5/20/20 5:03 AM, Stefan Monnier wrote:
> AFAIK this function is only used in the
> extremely rare case that Elisp does
>
> (byte-code "blabla")
>
> So I think some of the checks you removed from `exec_byte_code` will
> simply not be performed any more (at least not on
> `byte-code-function-p` objects).
Thanks for reviewing the patch.
What checks do you have in mind? Formerly, exec_byte_code did this:
CHECK_STRING (bytestr);
CHECK_VECTOR (vector);
CHECK_FIXNAT (maxdepth);
if (STRING_MULTIBYTE (bytestr))
bytestr = Fstring_as_unibyte (bytestr);
Now, byte-code does this:
if (! (STRINGP (bytestr) && VECTORP (vector) && FIXNATP (maxdepth)))
error ("Invalid byte-code");
if (STRING_MULTIBYTE (bytestr))
bytestr = Fstring_as_unibyte (bytestr);
and to my eye this does everything that exec_byte_code used to do.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master f0b0105: Hoist some byte-code checking out of eval
2020-05-20 21:21 ` Paul Eggert
@ 2020-05-20 23:21 ` Stefan Monnier
2020-05-21 0:54 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-05-20 23:21 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
>> AFAIK this function is only used in the
>> extremely rare case that Elisp does
>> (byte-code "blabla")
>> So I think some of the checks you removed from `exec_byte_code` will
>> simply not be performed any more (at least not on
>> `byte-code-function-p` objects).
>
> Thanks for reviewing the patch.
>
> What checks do you have in mind? Formerly, exec_byte_code did this:
>
> CHECK_STRING (bytestr);
> CHECK_VECTOR (vector);
> CHECK_FIXNAT (maxdepth);
> if (STRING_MULTIBYTE (bytestr))
> bytestr = Fstring_as_unibyte (bytestr);
>
> Now, byte-code does this:
>
> if (! (STRINGP (bytestr) && VECTORP (vector) && FIXNATP (maxdepth)))
> error ("Invalid byte-code");
>
> if (STRING_MULTIBYTE (bytestr))
> bytestr = Fstring_as_unibyte (bytestr);
>
> and to my eye this does everything that exec_byte_code used to do.
My point is that 99% of the calls to `exec_byte_code` don't go through
`Fbyte_code`.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master f0b0105: Hoist some byte-code checking out of eval
2020-05-20 23:21 ` Stefan Monnier
@ 2020-05-21 0:54 ` Paul Eggert
2020-05-21 2:30 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2020-05-21 0:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On 5/20/20 4:21 PM, Stefan Monnier wrote:
> My point is that 99% of the calls to `exec_byte_code` don't go through
> `Fbyte_code`.
Those other calls are also supposed to arrange for the relevant checks
to be done, typically when the objects given to exec_byte_code were
created. It saves some time to do the checks once on object creation
rather than every time the byte code is called.
At least, that was the idea. Did I miss a path of execution that skips
the checks?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master f0b0105: Hoist some byte-code checking out of eval
2020-05-21 0:54 ` Paul Eggert
@ 2020-05-21 2:30 ` Stefan Monnier
2020-05-21 5:26 ` Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-05-21 2:30 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
>> My point is that 99% of the calls to `exec_byte_code` don't go through
>> `Fbyte_code`.
> Those other calls are also supposed to arrange for the relevant checks to be
> done, typically when the objects given to exec_byte_code were created. It
> saves some time to do the checks once on object creation rather than every
> time the byte code is called.
I understand, but looking at the patch and the comment message, I see
that you moved the checks from exec_byte_code to Fbyte_code and moved
duplicated *some* of the checks in make_byte_code but not all of them.
I probably missed something,
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master f0b0105: Hoist some byte-code checking out of eval
2020-05-21 2:30 ` Stefan Monnier
@ 2020-05-21 5:26 ` Paul Eggert
2020-05-21 13:35 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2020-05-21 5:26 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On 5/20/20 7:30 PM, Stefan Monnier wrote:
> I understand, but looking at the patch and the comment message, I see
> that you moved the checks from exec_byte_code to Fbyte_code and moved
> duplicated *some* of the checks in make_byte_code but not all of them.
Oh, now that you mention it I do see something missing: Fbyte_code
converts bytestr to unibyte whereas Fmake_byte_code merely checks that
bytestr is unibyte, and I suppose it should be consistent with
Fbyte_code here. I'll look into fixing that. This should matter only
when dealing with Emacs 20.2-and-older bytecode strings (do we still
need to worry about that?).
You wrote "*some* .. but not all", which vaguely implies that I was
missing more than one check. Am I missing something else here?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master f0b0105: Hoist some byte-code checking out of eval
2020-05-21 5:26 ` Paul Eggert
@ 2020-05-21 13:35 ` Stefan Monnier
0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2020-05-21 13:35 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Oh, now that you mention it I do see something missing: Fbyte_code converts
> bytestr to unibyte whereas Fmake_byte_code merely checks that bytestr is
> unibyte, and I suppose it should be consistent with Fbyte_code here. I'll
> look into fixing that. This should matter only when dealing with Emacs
> 20.2-and-older bytecode strings (do we still need to worry about that?).
>
> You wrote "*some* .. but not all", which vaguely implies that I was missing
> more than one check. Am I missing something else here?
I just saw that the checks were not textually the same (I expected
basically "exactly" the same code to be duplicated to `Fbyte_code` and
`make-byte-code`; not sure if `Ffetch_bytecode` also needs some of that
treatment).
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-05-21 13:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20200520062521.6783.95407@vcs0.savannah.gnu.org>
[not found] ` <20200520062523.3EF4A20AEB@vcs0.savannah.gnu.org>
2020-05-20 12:03 ` master f0b0105: Hoist some byte-code checking out of eval Stefan Monnier
2020-05-20 21:21 ` Paul Eggert
2020-05-20 23:21 ` Stefan Monnier
2020-05-21 0:54 ` Paul Eggert
2020-05-21 2:30 ` Stefan Monnier
2020-05-21 5:26 ` Paul Eggert
2020-05-21 13:35 ` Stefan Monnier
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.