Hi Gray, Sorry, I got sidetracked with the rest of the discussion and forgot to come back to this until now.
On Fri, Sep 12, 2014 at 5:48 PM, Gray Calhoun <[email protected]> wrote: > > 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). > After compilation, Match.jl is basically a bunch of nested "if" statements. For simple things, where you're always checking against the same type (e.g., Expr), there may be a slight compilation overhead, but no execution overhead. When things get more complicated, the main potential for slowdown (I think) is when matching against arrays. 1. the nested "if"s contain explicit array size/bounds checks, in order to avoid bounds errors and try/next blocks 2. SubArrays are used to match parts of multidimensional arrays, and SubArrays are currently a little slow in Julia Also, as with any Julia code, wrapping in a function will greatly improve type inference, and hence performance. Finally, matching against Expr is quite functional, but slightly annoying: Exprs are constructed with Expr(:+, 1,2,3) but the actual Expr object contains the "1,2,3" in an array, and has an additional type field. So Expr rewriting currently looks something like Expr(:+, [a,b,c], _) => Expr(:+, c,b,a) I've thought about special casing Expr specifically to avoid this, but haven't gotten around to it. I used Match.jl quite extensively to match and rewrite Exprs when wrapping VideoIO. A clean Expr match example is https://github.com/kmsquire/VideoIO.jl/blob/master/util/wrap_libav_split.jl#L215-L226. You can search in the rest of that file for examples of Expr rewriting. Hope this is useful. Cheers! Kevin
