[cfe-commits] [Patch] -Wduplicate-enum which fixes PR6343

[Ted Kremenek]

Ok.  That's still a scary number.  Do you have numbers for realistic examples?  For example, we know Clang has some particularly large enums.  This micro benchmark is useful, but it may be overly pessimistic.

On Jul 25, 2012, at 2:34 PM, Richard Trieu <rtrieu at google.com> wrote:

> Yes, that is the slowdown for the entire -fsyntax-only time for a source file with only an enum in it.
> 
> On Wed, Jul 25, 2012 at 1:48 PM, Ted Kremenek <kremenek at apple.com> wrote:
> Hi Richard,
> 
> If I am reading that right, the 6-10% slowdown is for the entire -fsyntax-only time?  If so, that's definitely cost prohibitive.
> 
> Ted
> 
> On Jul 19, 2012, at 8:25 PM, Richard Trieu <rtrieu at google.com> wrote:
> 
>> On Wed, Jul 18, 2012 at 9:14 PM, Ted Kremenek <kremenek at apple.com> wrote:
>> On Jul 18, 2012, at 6:34 PM, Richard Trieu <rtrieu at google.com> wrote:
>> 
>>> A set could work for detecting the values, but both EnumConstantDecls are needed for the diagnostic, not just the values.  Possibly a map from APSInt->EnumConstantDecl* would work.  But either way, I would be dealing with getting APSInts to play nice with each other.
>> 
>> That seems reasonable to me.  The primary performance issue I see is the quadratic algorithmic complexity.  If the APSInt comparisons are an issue, we can see if we can find ways to optimize that further.
>> 
>> I created two more variations on and measured some timings.  Both used a map, one with a custom compare function and one that extended the APSInt value before insertion.  The APSInt extension had the better time, so I'll be giving the number for that one.
>> 
>> At 10,000 elements, there was a 6-10% slow down.  This amounts to .01-.03 seconds difference on .13-.27 second runtime.
>> 
>> At 100,000 elements, 8-12% slow down.  .2-.3 seconds on 1.34 to 2.66 second run time.
>> 
>> At 1,000,000 elements, 7-14% slow down.  Around 2 second difference for runs of 13.6 to 26.7 seconds.
>> 
>> A new patch has been attached which has the APSInt bit extension before adding to the map.
>> <duplicate-enum-bit-extension.patch>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120725/ba357ef0/attachment.html>