[cfe-dev] Expression Templates for AST matchers
Richard
legalize at xmission.com
Thu Apr 9 10:15:02 PDT 2015
In article <CAOsfVvmev4Y7Q=Wr=8RJQFs49S94J0OE97-iJyaWRZVvCD60Jg at mail.gmail.com>,
Manuel Klimek <klimek at google.com> writes:
> We actually went from a more expression templatey to a less expression
> templatey design.
Interesting! So far, I feel like what I've been trying to match is
completely expressable at compile-time and deferring things to runtime
is making things slow. This seems to be consistent with the findings
of the imlpementors of OCLint and why they make the statement I quoted
earlier.
> On Tue, Apr 7, 2015, 3:31 PM Sean Silva <chisophugis at gmail.com> wrote:
>
> > Although I'm mostly an armchair spectator right now w.r.t. clang tooling
> > stuff, I think that use cases like clang-query and in general the dynamic
> > AST matchers suggests that expression templates aren't a very good solution
> > because they will require reimplementing things from scratch for the
> > "dynamic" case.
When I look at a library like Boost.Spirit that heavily uses
expression templates I don't see how I'm losing the dynamic case at
all. Maybe I'm misunderstanding what you're saying.
> Sam has worked on making clang tidy use cases faster. I
> expect in the end the right thing is to do less duplicate work which I
> think we will be able to do with modules.
While modules are nice, I don't think it's reasonable to expect that
modules will be deployed over a significant chunk of the world's C++
code anytime soon. So it doesn't seem practical to say "modules will
fix this".
> > Regardless, I don't think that the primary bottleneck is not doing enough
> > at compile time (of the matchers). Rather we aren't effectively indexing
> > the underlying data set we are trying to query (right now, we're more like
> > grep and less like google). [...] (a
> > good example is using a trigram index to prune the search space for regexp
> > matching http://swtch.com/~rsc/regexp/regexp4.html).
> >
> > * "multiple" here also scales numerically with the number of TU's. An
> > index can avoid visiting certain TU's at all in many cases.
Thanks for that link Sean, that was an interesting read. I couldn't
find it "live" on the web, but was able to get it via the wayback
machine on archive.org.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
More information about the cfe-dev
mailing list