Avoiding allocation during parsing could really be helpful. It would be possible to make the number of subexpressions a type parameter.
On Sun, Sep 14, 2014 at 12:52 AM, Jake Bolewski <[email protected]> wrote: > 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]> >> 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:_e(%7B%7D,'cvml','[email protected]');>> 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). >> >>
