================
@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
const char *file_name = file.GetFilename().AsCString("<Unknown>");
LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
- Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+ Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+ Progress::ProgressReportType::eAggregateProgressReport);
----------------
clayborg wrote:
If the goal is to get rid of super spammy notifications (ones that are too
quick), that can actually be done client side when the progress notification
events are received by setting a timeout once the start progress has been
received, and if a certain timeout happens (more than 1 second), then just
don't show the progress, but if it does last then pop the progress dialog up.
We tried this in lldb-dap.cpp. See the function named `void
ProgressEventThreadFunction()` which is:
```
void DAP::SendProgressEvent(uint64_t progress_id, const char *message,
uint64_t completed, uint64_t total) {
progress_event_reporter.Push(progress_id, message, completed, total);
}
```
We have a class called `ProgressEventReporter`:
```
/// Class that filters out progress event messages that shouldn't be reported
/// to the IDE, because they are invalid, they carry no new information, or they
/// don't last long enough.
///
/// We need to limit the amount of events that are sent to the IDE, as they slow
/// the render thread of the UI user, and they end up spamming the DAP
/// connection, which also takes some processing time out of the IDE.
class ProgressEventReporter {
```
The problem we ran into with sending tons of notifications through the debug
adaptor protocol was it was too many packets, so we trimmed them down. The main
issue with this approach is if you get 1000 progress notifications and each
progress takes less than the minimum report time, like 1 second, and if each
progress takes just under the timeout of 1 second, you have a long delay with
no feedback.
For progress notifications like the DWARF manual index, it has a total count of
the number of compile units and each time a compile unit is indexed, the
progress gets advanced and can cause a ton of update packets to be sent, this
class helps reduce these.
So the `ProgressEventReporter` class will:
- not report events if they are too quick, but if they exceed a minimum
threshold, they get report, albeit a bit late
- if there is a progress that is really spammy (1 of 10000, 2 of 10000, 3 of
10000, etc) it will report progress only every so often. This really reduces
the number of progress notifications.
https://github.com/llvm/llvm-project/pull/69516
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
