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 <[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. > <duplicate-enum-bit-extension.patch>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
