On Jan 21, 2009, at 1:56 PM, Daniel Dunbar wrote:
Ok. Are you able/willing to investigate or should I try to con someone
else into it?
- Daniel
Daniel, thanks for staying on top of this issue.
On Wed, Jan 21, 2009 at 1:33 PM, Sebastian Redl
<[email protected]> wrote:
Daniel Dunbar wrote:
My performance tester is pointing at this for a 2.5% regression in
syntax only time. Is this inherent and the price we have to pay for
cleanup, or unexpected?
Unexpected. I do some very rough performance testing on every bunch I
convert and never notice a slowdown. There is an inherent price (the
smart pointers carry around a pointer to the Action all the time),
but I
expected it to be unnoticeable.
Sebastian, when we decided to move forward with this, we agreed it was
important to do "A/B comparisons" (see below). By analogy, this
pattern needs to be like "0-cost" exceptions (where entering a block
is 0-cost). Parsing valid code should be 0-cost (or darn close to it).
Thanks for understanding our performance goals,
snaroff
Begin forwarded message:
From: steve naroff <[email protected]>
Date: December 19, 2008 8:35:13 AM PST
To: clang-dev Developers <[email protected]>
Subject: Smart pointer usage in the Parser/Actions
Folks,
Over the past week or so, there's been some discussion about making
extensive use of smart pointers in the parser (on clang-dev).
Since the change is pervasive (and influences the programming
model), we discussed the topic yesterday (with Apple compiler
engineers working on clang).
We concluded it makes sense to follow-through with the changes. Our
only concern is performance: we don't want to degrade performance of
parsing correct code. For example, parsing system headers remains a
bottleneck. Since system headers don't contain invalid code, it's
important this improvement not degrade performance. Once the change
is complete, it's important we do "A/B comparisons" to measure the
performance for parsing valid code.
Once we have the data, we can decide if the cost is worth the
benefit. We don't anticipate a major slowdown, however given the
scope of the change (and frequency of calling "move"), it's
something we need to verify.
We'd like to thank Sebastian for tackling this project!
snaroff
Sebastian
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
