<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
19.06.2012 16:35, Manuel Klimek wrote:<br>
<blockquote
cite="mid:CAOsfVvkKGTj-TegBaO45XvCg+q0Ci0jXB6oRbts_obN3imJMvA@mail.gmail.com"
type="cite">
<div style="font-family: arial,helvetica,sans-serif;"><font
size="2">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im">
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font
size="2">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<blockquote type="cite">
<div
style="font-family:arial,helvetica,sans-serif"><font
size="2">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
text="#000000"> Or maybe
about some interactive
(maybe gui) tool for
building predicates? I
remember that Chandler
mentioned about something
similar at <a
moz-do-not-send="true"
href="http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s"
target="_blank">http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s</a>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Now we're talking the next
step :) Yea, having a GUI
would be *great* (and just so
we're clear: with GUI I mean a
web page :P)</div>
</div>
</font></div>
</blockquote>
<br>
</div>
And maybe AST database optimized for fast
predicate matches :)<br>
</div>
</blockquote>
<div><br>
</div>
<div>For small projects this might be
interesting - for us the question is how
that would scale - we've found parsing the
C++ code to be actually an interesting way
to scale the AST, for the small price of
needing up 3-4 seconds per TU (on average).
Denormalizing the AST itself produces a huge
amount of data, and denormalizing even more
seems like a non-starter.</div>
<div><br>
</div>
<div>Thoughts?</div>
</div>
</font></div>
</blockquote>
<br>
</div>
It depends on how much you would like to scale. And yes,
it also depends on project sizes.<br>
For instance, if required scaling is task per TU - it is
one case.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Perhaps I need to expand on what I mean here:</div>
<div>Imagine you have on the order of 100MLOC.</div>
<div>
If you want an "AST database" for predicate matches, the
question is what indexes you create. If you basically want
to create an extra index per "matcher", the
denormalization takes too much data. If you don't create
an index per matcher, how do you efficiently evaluate
matchers?</div>
</div>
</font></div>
</blockquote>
<br>
I understood that part of previous message.<br>
My point was, that if you have 1k translation units and need to
scale up to 100k parallel tasks, then it is obvious that "task per
TU" is not sufficient, and need to use another approach (maybe
pre-parse and split AST).<br>
<br>
Best Regards,<br>
Evgeny<br>
</body>
</html>