[cfe-commits] r60900 - in /cfe/trunk: include/clang/Parse/Ownership.h

[fjahanian]

One of the approaches that gcc has used successfully throughout the  
years has been to branch out for application of
specific technologies. It can be merged in after the successful proof  
of technology in the branch. Can we do this
for this and future application of new programming paradigms on  
clang, I wonder?

- Fariborz

On Dec 13, 2008, at 3:21 PM, Sebastian Redl wrote:

> Sebastian Redl wrote:
>> Fariborz Jahanian wrote:
>>
>>> I am having the same concerns as Steve. We are adding enormous level
>>> of abstractions without looking at its consequences down the  
>>> road.  Aren't we
>>> concerned about potential performance implications for one  
>>> (smart  pointers don't
>>> get smart for  cheap :).
>>>
>> They're not free, but they are pretty cheap. However, Doug messed  
>> up my planned performance test by doing his name lookup rework at  
>> the same time as I did the replacements. I still plan to do some  
>> serious testing soon; however, I expect the largest impact to come  
>> from transforming the Action interface to smart pointers, and I  
>> have only started with this.
>>
> So I did some rough performance testing. My test method was thus:
>
> time Release/bin/clang -fsyntax-only insn-attrtab.i
>
> where insn-attrtab.i is a preprocessed version of GCC's insn- 
> attrtab.c, a generated 3.3MB behemoth consisting mostly of a huge  
> switch statement.
>
> I went through the SVN log and tested every version directly before  
> and after every smart pointer-related commit of mine. I'm happy to  
> say that over the entire length of the tested area (-r 60760:60983)  
> the average user time needed to process the file has not changed  
> significantly. A rough average (read: me running the command 5-10  
> times and taking a number that appeared to be in the middle of the  
> observed times) went from 0.50 for 60760 to 0.52 for 60983, with a  
> variation of +-0.03. I conclude that the changes done so far had no  
> significant impact on performance.
>
> I'll keep testing.
>
> Sebastian