On Thu, 3 Apr 2008, Sam TH wrote:
> On Tue, Apr 1, 2008 at 12:42 PM, Dimitris Vyzovitis <vyzo at media.mit.edu> wrote:
> [snip]
> First, using `comp=?' is not sufficient here, because of the presence
> of the JIT. But if you have programs on which you can measure the
> speed difference introduced by the extra bindings, I'd be interested.
>
I can compile some microbenchmarks, but I think the old match
performance tests with random lists (the ones recently moved to the attic)
might do.
> >
> > See (using matthew's comp=?):
> [snip]
> > >
> > > This is something that can, and hopefully will, be improved. It's a
> > > fairly straightforward optimization, but not one that I've had time to
> > > implement yet.
> >
> > If you get around doing that, can you generalize it for (app ...) patterns
> > and not just the built-in expanders?
>> I've committed a reordering pass which should alleviate some of the
> redundant checking here. But I'm not sure what you want me to
> optimize about (app ...) patterns. Can you explain?
>
basically merge branches that call the same function by name:
(app foo pat1)
(app foo pat2)
This will ensure that custom expands that expand on structs (for example)
will do the right thing and behave just like a builtin would do.
-- vyzo