jingham added a comment. I was about to say this shouldn't matter, since most people don't run with timers enabled and the timers should be no-ops when timing is off. But LLDB_SCOPED_TIMER seems to do a bunch of work even when the timers are disabled. The work includes "look up the Category in the map of categories, making a new one if not found", get the current time of day and stash that away, and do whatever the Signpost chooses to do on entry & exit. So this would be adding non-trivial work for everybody for every SB API call.
Is this really necessary? Seems like you could have LLDB_SCOPED_TIMER do nothing if the Timer::g_display_depth == 0. That would mean that you wouldn't get timings for the remaining bit of any timers that would have been active when you enabled the timers, but that doesn't seem particularly wrong to me... I'm a little confused about what you want to achieve as well. You said you want to see "on whose behalf LLDB spends time". This change will tell you that during the course of the debug session, SBWatchpoint::SetSP consumed N seconds, and SBWatchpoint::GetSP M seconds. It will also dump some text to the console when an SB API is called, but I'm not sure how you would get access to that info and attribute it back to the caller. But the timers don't record stacks, so you won't know anything about the callers, you will just know that that SB API consumed N seconds. I'm not sure how that tells you "on whose behalf lldb spends time". Of course, the Signpost call could do anything you want, so you could have a variant that captures stacks, but then these calls are going to get even more expensive... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117632/new/ https://reviews.llvm.org/D117632 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
