Hitting LexIdentifier with a minor performance hit

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Hitting LexIdentifier with a minor performance hit

Sean Hunt
Hey,

I'd like to split LexIdentifier into two functions so that the actual
identifier lexing logic can be reused for user-defined literal suffixes.
Since this is a change to the lexing code that will probably have a
negative performance impact, however slight (one function call of
overhead per identifier is added; one goto is removed per "nasty"
identifier (a \, $, or ? is present)), I wanted to check it by first.

The effective change is that the literal lexing code will be able to use
LexIdentifierInternal to parse the suffix when I add that in.

Sean

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

lexidentifier.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hitting LexIdentifier with a minor performance hit

Chris Lattner

On Dec 4, 2009, at 12:40 PM, Sean Hunt wrote:

> Hey,
>
> I'd like to split LexIdentifier into two functions so that the actual identifier lexing logic can be reused for user-defined literal suffixes. Since this is a change to the lexing code that will probably have a negative performance impact, however slight (one function call of overhead per identifier is added; one goto is removed per "nasty" identifier (a \, $, or ? is present)), I wanted to check it by first.
>
> The effective change is that the literal lexing code will be able to use LexIdentifierInternal to parse the suffix when I add that in.

This is one of the most performance sensitive pieces of the entire compiler.  Is there any other way to avoid this (e.g. through code duplication or macros)?  Have you measured the performance impact of this change?

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hitting LexIdentifier with a minor performance hit

Sean Hunt
Chris Lattner wrote:

> On Dec 4, 2009, at 12:40 PM, Sean Hunt wrote:
>
>> Hey,
>>
>> I'd like to split LexIdentifier into two functions so that the actual identifier lexing logic can be reused for user-defined literal suffixes. Since this is a change to the lexing code that will probably have a negative performance impact, however slight (one function call of overhead per identifier is added; one goto is removed per "nasty" identifier (a \, $, or ? is present)), I wanted to check it by first.
>>
>> The effective change is that the literal lexing code will be able to use LexIdentifierInternal to parse the suffix when I add that in.
>
> This is one of the most performance sensitive pieces of the entire compiler.  Is there any other way to avoid this (e.g. through code duplication or macros)?  Have you measured the performance impact of this change?
>
> -Chris

Output of 'time make test' without patch:

real    0m36.170s
user    0m21.965s
sys     0m10.453s

real    0m24.046s
user    0m22.269s
sys     0m9.789s

real    0m23.655s
user    0m22.085s
sys     0m10.157s

real    0m23.617s
user    0m21.821s
sys     0m10.113s

real    0m24.389s
user    0m22.213s
sys     0m10.029s

with patch:

real    0m26.394s
user    0m22.121s
sys     0m10.365s

real    0m24.502s
user    0m22.161s
sys     0m10.017s

real    0m24.139s
user    0m22.213s
sys     0m10.073s

real    0m23.997s
user    0m22.253s
sys     0m10.085s

real    0m23.894s
user    0m22.057s
sys     0m10.033s

Sean
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hitting LexIdentifier with a minor performance hit

Chris Lattner

On Dec 8, 2009, at 9:21 PM, Sean Hunt wrote:

> Chris Lattner wrote:
>> On Dec 4, 2009, at 12:40 PM, Sean Hunt wrote:
>>
>>> Hey,
>>>
>>> I'd like to split LexIdentifier into two functions so that the actual identifier lexing logic can be reused for user-defined literal suffixes. Since this is a change to the lexing code that will probably have a negative performance impact, however slight (one function call of overhead per identifier is added; one goto is removed per "nasty" identifier (a \, $, or ? is present)), I wanted to check it by first.
>>>
>>> The effective change is that the literal lexing code will be able to use LexIdentifierInternal to parse the suffix when I add that in.
>>
>> This is one of the most performance sensitive pieces of the entire compiler.  Is there any other way to avoid this (e.g. through code duplication or macros)?  Have you measured the performance impact of this change?
>>
>> -Chris
>
> Output of 'time make test' without patch:

make test isn't a very interesting way to test the performance of this, because it is dominated by other things.  Make sure you have a release-asserts build (do make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1) then do something like this:

clang -E -P somethinglarge.m -o out.mi (or .cpp)
time clang-cc -Eonly out.mi

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Loading...