It's not a level-of-abstraction difference. A predicate use
(s? o)
is compiled as
(or (authentic-s? o) (and (impersonator? o)
(authentic-s? (impersonator-original o))))
where `authentic-s?` and `impersonator?` are a type-tag tests. I agree
that the extra `impersonator?` test should be well predicted, but it
still has a measurable cost in the one program I tied. I don't know
whether the cost is due to the branch or just the extra code involved.
I agree that generally don't want performance declarations that
interfere with reasonable interposition. The good uses of `#:authentic`
would be in places where the struct representation of a value is not
exposed or where the values themselves are not exposed (so any
interposition means being on the "inside" where you can change the
code, anyway).
At Thu, 11 May 2017 12:21:25 -0400, Scott Moore wrote:
> Out of curiosity, where does the additional overhead come from? Without
> looking at the struct predicate code, I would have expected this to be a
> relatively-well predicted branch on the Scheme_Type of the object. I haven’t
> been following the Chez port though—are impersonators being implemented at a
> higher level of abstraction?
>
> That aside, I don’t think there is too much lost from doing this—as you
> mention, it was already possible to create structs that could not be easily
> impersonated.
> There are some edge cases this would change though, where you use the program
> structure to make sure you have the right inspector around. For something
> like
> the expander, that’s probably not an issue, as the expander will be running
> before the program has a chance to intervene.
>
> I think the main danger would be if it was abused for the performance benefit
> in libraries where a client might reasonably want to interpose...
>
> On May 11, 2017, 11:16 AM -0400, Matthew Flatt <[email protected]>, wrote:
> > There are many structure types that are private to some library (such
> > as the expander) and will never have impersonators. The compiler can't
> > know that, though, and the possibility of an impersonator means that
> > the structure type's predicate has to be twice as expensive. Field
> > selection is also more expensive in certain cases. I'm not sure about
> > the current Racket VM, but the cost is measurable when running the
> > Racket expander on Chez Scheme.
> >
> > So, I'm thinking of adding a `prop:authentic` structure type property
> > --- with an `#:authentic` shorthand for `struct` --- that prevents
> > instances of a structure type from being impersonated or chaperoned.
> > Naturally, an authentic structure type's supertype and subtypes must
> > also be authentic.
> >
> > Any opinions?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> > To post to this group, send email to [email protected].
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/59148060.14da620a.a334b.158bSMTPIN
> _ADDED_MISSING%40gmr-mx.google.com.
> > For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/20170511164222.81E6965006D%40mail-svr1.cs.utah.edu.
For more options, visit https://groups.google.com/d/optout.
