On Thu, Jul 19, 2012 at 8:25 PM, Richard Trieu <[email protected]> wrote:
> On Wed, Jul 18, 2012 at 9:14 PM, Ted Kremenek <[email protected]> wrote: > >> On Jul 18, 2012, at 6:34 PM, Richard Trieu <[email protected]> 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. > Added some logic to avoid warning on: enum { A1, A2 = A1 }; Changed the wording to remove "previous" since the element could have been declared afterwards.
duplicate-enum-bit-extension2.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
