On Fri, Oct 11, 2013 at 2:41 PM, Eric Christopher <[email protected]>wrote:
> >>> Do you have any evidence that this adversely affects debugger > >>> performance? > >> > >> For our internal tool chains, we now have to perform a string search to > >> find the definition. In theory, the extra search should make it slower. > > > > > > It'd be really nice to quantify this. > > > >> > >> Yes, the accelerator table can help the search. > >> > > The accelerator table should help - since it only has definitions and > it's on by default for darwin. What's up that's causing a performance > degradation? > I don't have numbers right now, in theory extra search means slower response (maybe insignificant). I was asking whether it is worthwhile to guard this change with a flag. If -no-limit-debug-info is not the right flag, is it reasonable to have a different flag for this? Does gcc has a flag to turn this off? Manman > -eric > > >>> > >>> > >>>> > >>>> Is it reasonable for this commit to be enabled only for > >>>> limit-debug-info, when no-limit-debug-info is on, we don't see > effects of > >>>> this patch? > >>> > >>> > >>> GCC does this by default, at least on Linux - I haven't tested on > MacOS. > >>> I would guess it does so there too (but as you point out, there are > >>> different tradeoffs there, so I might be wrong). > >>> > >>> I'd like to understand the performance tradeoff to justify such a > large > >>> regression in debug info size (it's worth about ~20% on Clang/LLVM > based on > >>> my experiments). > >> > >> > >> Our default is -limit-debug-info, so this will be on by default. I was > >> asking whether we should guard this so when people use > >> "-fno-limit-debug-info", they will get the definition. > > > > > > -flimit-debug-info has some relatively rough heuristics that aren't as > high > > confidence as the vtable based debug info emission mechanism, I'm not > sure > > we want to group these together. (eg: it seems likely that a user might > have > > issues with the minimization caused by -flimit-debug-info and want to > turn > > it off, if in doing so they also turn off the vtable based, > > higher-confidence optimization, that would be unfortunate) > > > > - David > > > >> > >> > >> Thanks, > >> Manman > >> > >>> > >>> > >>> > >>> - David > >>> > >>>> > >>>> > >>>> Thanks, > >>>> Manman > >>>> > > > > > > _______________________________________________ > > cfe-commits mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
