[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

[Greg Clayton via lldb-commits]

================
@@ -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