Performance would come from reducing the allocation of unnecessary Any[]
arrays for a handful of expression nodes, which has some overhead.
Serialization / deserialization of the AST could potentially be faster
under a more compact representation as we know that hitting the gc is a
performance bottleneck when doing large amounts of (de)serialization.
These two factors have some impact on startup time as well.
One version of a function could handle all parametric expression types, it
would just have to do runtime lookup similar to what you would have to do
now,
so isa(arg, Expr) && (arg::Expr).head === :headB would then just become
isa(arg, Expr{:headB}).
I wouldn't suspect this optimization to have a large impact on performance,
but it could make things a some % faster (you hope).
On Saturday, September 13, 2014 6:06:02 PM UTC-4, Tim Holy wrote:
>
> I wonder whether it would really have much of a performance advantage.
> Usually
> expressions are nested, and so an Expr{:headA} contains among its args an
> Expr{:headB}. But you don't know until runtime what type it is, so runtime
> lookup would have to be faster than
> isa(arg, Expr) && (arg::Expr).head == :headB ...`
> I don't actually know, but I would be a bit surprised if it would help
> that
> much.
>
> Before someone thinks about tackling this, it would make sense to mock it
> up;
> make a MyExpr{:headsym}, nest a bunch of them based on real expressions,
> and
> then see if you get any real benefit from having the head as a type
> parameter.
>
> The other negative is it would add to compilation time---currently one
> version
> of a function handles all expressions, but with this change you'd have to
> compile a version for each parametric expression type. That means yet
> slower
> startup of any packages that do expression-parsing, and startup speed is
> already a pretty big problem.
>
> --Tim
>
> On Saturday, September 13, 2014 01:17:00 PM Kevin Squire wrote:
> > While this would greatly affect Match.jl, it would be a very welcome
> change!
> >
> > Cheers,
> > Kevin
> >
> > On Saturday, September 13, 2014, Leah Hanson <[email protected]
> <javascript:>> wrote:
> > > I would expect the Expr type to be abstract, with different concrete
> > > subtypes for each current value of head. Each value of head indicates
> a
> > > specific structure in args, and this can just be reflected in the
> > > definition of the subtypes. (Then you can dispatch on Expr type, use
> > > "subtypes(Expr)" to see all possible kinds of Expr, etc.)
> > >
> > > -- Leah
> > >
> > > On Sat, Sep 13, 2014 at 10:47 AM, Jake Bolewski <[email protected]
> <javascript:>
> > >
> > > <javascript:_e(%7B%7D,'cvml','[email protected] <javascript:>');>>
> wrote:
> > >> We've actually discussed changing our expression representation to
> use
> > >>
> > >>>> types instead of the more lisp-like symbols for distinguishing
> > >>>> expression
> > >>>> types. That would allow dispatch on expression types and be more
> > >>>> compact.
> > >>>> It would, however, break almost all macros that do any kind of
> > >>>> expression
> > >>>> inspection.
> > >>
> > >> Hmm, interesting. I guess the Expr type would then be Expr{:head}
> with
> > >> getindex / setindex overloaded to manipulate the arguments? This
> would
> > >> be
> > >> a nice change as for many nodes you would not have to allocate an
> args
> > >> array which could be a performance win (i guess the serialized ast's
> > >> would
> > >> be more compact as well). Can't comment on whether it would be
> enough of
> > >> a
> > >> win to justify such a massively breaking change.
> > >>
> > >>> On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun <[email protected]>
> > >>>
> > >>>> wrote:
> > >>>>> On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G.
> Johnson
> > >>>>>
> > >>>>> wrote:
> > >>>>>> On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>> Are there better ways to do this in general?
> > >>>>>>
> > >>>>>> For this kind of expression-matching code, you may find the
> Match.jl
> > >>>>>> package handy (https://github.com/kmsquire/Match.jl), to get ML-
> or
> > >>>>>> Scala-like symbolic pattern-matching.
> > >>>>>
> > >>>>> Thanks, that's pretty cool. For simple cases like I'm using, do
> you
> > >>>>> know if there are advantages (or disadvantages) to using Match.jl,
> or
> > >>>>> should I just view it as a nicer syntax? (Obviously, when things
> get
> > >>>>> more
> > >>>>> complicated Match.jl looks very appealing).
>
>
