5 Commits

Author SHA1 Message Date
Chelsea Cassanova
c846f8ba10
[lldb][progress] Always report progress upon Progress object destruction (#73605)
This commit allows a final progress report upon the destruction of the
`Progress` object to happen at all times as opposed to when the progress
was not completed.
2023-11-28 10:45:02 -08:00
Pavel Labath
afe8f20bb8 Revert "[lldb] Rate limit progress reports -- different approach [WIP-ish]"
This reverts commit c30853460da7446f92bc1e516f9cbe2c5df6e136, which I
pushed accidentally -- sorry.
2023-06-16 09:09:56 +02:00
Pavel Labath
c30853460d [lldb] Rate limit progress reports -- different approach [WIP-ish]
Have the Progress class spawn a thread to periodically send progress
reports.

The reporting period could be made configurable, but for now I've
hardcoded it to 100ms. (This is the main WIP part)

It could be argued that creating a thread for progress reporting adds
overhead, but I would counter that by saying "If the task is so fast
that creating a thread noticably slows it down, then it really doesn't
need progress reporting".

For me, this speeds up DWARF indexing by about 1.5% (which is only
slightly above the error bars), but I expect it will have a much bigger
impact in situations where printing a single progress update takes a
nontrivial amount of time.

Differential Revision: https://reviews.llvm.org/D152364
2023-06-16 08:28:29 +02:00
Jonas Devlieghere
129eb5bcab
[lldb] Add the ability to provide a message to a progress event update
Consider the following example as motivation. Say you have to load
symbols for 3 dynamic libraries: `libFoo`, `libBar` and `libBaz`.
Currently, there are two ways to report process for this operation:

 1. As 3 separate progress instances. In this case you create a progress
    instance with the message "Loading symbols: libFoo", "Loading
    symbols: libBar", and "Loading symbols: libBaz" respectively. Each
    progress event gets a unique ID and therefore cannot be correlated
    by the consumer.

 2. As 1 progress instance with 3 units of work. The title would be
    "Loading symbols" and you call Progress::Increment for each of the
    libraries. The 3 progress events share the same ID and can easily be
    correlated, however, in the current design, there's no way to
    include the name of the libraries.

The second approach is preferred when the amount of work is known in
advance, because determinate progress can be reported (i.e. x out of y
operations completed). An additional benefit is that the progress
consumer can decide to ignore certain progress updates by their ID if
they are deemed to noisy, which isn't trivial for the first approach due
to the use of different progress IDs.

This patch adds the ability to add a message (detail) to a progress
event update. For the example described above, progress can now be
displayed as shown:

  [1/3] Loading symbols: libFoo
  [2/3] Loading symbols: libBar
  [3/3] Loading symbols: libBaz

Differential revision: https://reviews.llvm.org/D143690
2023-02-12 11:17:58 -08:00
Greg Clayton
e122877f10 Add a progress class that can track long running operations in LLDB.
LLDB can often appear deadlocked to users that use IDEs when it is indexing DWARF, or parsing symbol tables. These long running operations can make a debug session appear to be doing nothing even though a lot of work is going on inside LLDB. This patch adds a public API to allow clients to listen to debugger events that report progress and will allow UI to create an activity window or display that can show users what is going on and keep them informed of expensive operations that are going on inside LLDB.

Differential Revision: https://reviews.llvm.org/D97739
2021-03-24 12:58:13 -07:00