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

[Ted Kremenek]

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/fb1292e2/attachment.html>