labath wrote:
> @labath baseline for just attaching is approximately `3 s` for LLDB and `2.5
> s`. Baselines for attaching _and_ stopping at the breakpoint are in the
> `break only` rows of the table.
Thanks. I think this resolves my concerns about this patch. If we do find a
particularly
Michael137 wrote:
Now that we don't search for the definition DIE when initially parsing a DIE,
we could probably move this progress report to when we look for
`FindDefinitionTypeForDIE`, which seems to be the most expensive part of the
`DWARFASTParser`
Michael137 wrote:
@labath baseline for just attaching is approximately `3 s` for LLDB and `2.5
s`. Baselines for attaching *and* stopping at the breakpoint are in the `break
only` rows of the table.
https://github.com/llvm/llvm-project/pull/91452
Michael137 wrote:
Sorry for the delayed response, just got back from vacation.
> What do these numbers include? Is it just the operation it self, or
> everything leading up to it as well.
> Thanks for doing this. What do these numbers include? Is it just the
> operation it self, or
labath wrote:
> I attached to clang and printed an expression. That resulted in 16801 calls
> to `Progress::Increment`, all of which I'm guessing translate to event
> broadcasts. I collected some timing numbers:
Thanks for doing this. What do these numbers include? Is it just the operation
JDevlieghere wrote:
> @JDevlieghere I know we discussed this in the past and it made sense to me,
> but I'm right now failing to connect the dots. Why couldn't the same
> single-line interface be used to print nested events something like this?
>
> ```
> Evaluating expression > Type Checking
adrian-prantl wrote:
> No, on the terminal it works that way by design. Unless you switch to
> something that takes full control of your screen (like curses) there's no
> good way to display multiple progress events at the same time and not doing
> the shadowing (i.e. letting more recent
JDevlieghere wrote:
> @JDevlieghere @adrian-prantl are there plans to change the presentation layer
> to prevent this kind of shadowing in the future? Would be nice if all we
> needed to do was report progress, and not worry about other progress events
> in the debugger being in-flight
No,
Michael137 wrote:
I attached to clang and printed an expression. That resulted in 16801 calls to
`Progress::Increment`, all of which I'm guessing translate to event broadcasts.
I collected some timing numbers:
```
Michael137 wrote:
> I am somewhat worried about this slowing down the actual operations it is
> reporting progress on. I didn't really measure this, but intuitively, I'd
> expect that a one of these operations (parsing/importing one type) would be
> pretty fast, and that the whole process
https://github.com/clayborg commented:
How many notifications happen during an expression? We want to make sure this
doesn't slow down expression evaluation by any appreciable amount. If we spam
these notifications, without having any throttling in place (I have an open
patch for this I
JDevlieghere wrote:
> If this turns out to be necessary, one way to rate-limit them would be to
> have a nesting depth counter. Assuming that these imports happen recursively
> we could create only Progress objects for the top n layers.
Is the code that emits the progress event recursive too?
adrian-prantl wrote:
If this turns out to be necessary, one way to rate-limit them would be to have
a nesting depth counter. Assuming that these imports happen recursively we
could create only Progress objects for the top n layers.
https://github.com/llvm/llvm-project/pull/91452
JDevlieghere wrote:
> My understanding was that the progress increment is designed to be really
> cheap (writing two pointers) and that it's up to presentation layer to decide
> a t what frequency to update the UI.
>
> @JDevlieghere — is that perception correct?
You're correct about the
labath wrote:
> > I am somewhat worried about this slowing down the actual operations it is
> > reporting progress on. I didn't really measure this, but intuitively, I'd
> > expect that a one of these operations (parsing/importing one type) would be
> > pretty fast, and that the whole process
adrian-prantl wrote:
> I am somewhat worried about this slowing down the actual operations it is
> reporting progress on. I didn't really measure this, but intuitively, I'd
> expect that a one of these operations (parsing/importing one type) would be
> pretty fast, and that the whole process
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
labath wrote:
> cast nullptr to a
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
I am somewhat worried about this slowing down the actual operations it is
reporting progress on. I didn't really measure this, but intuitively, I'd
expect that a one of these operations (parsing/importing one type) would be
pretty fast, and that the whole
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
+clang::Decl const *From) {
+ assert(From &&
+
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
Michael137 wrote:
These asserts
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
bulbazord wrote:
The assertions in
@@ -1240,7 +1241,13 @@ TypeSP
SymbolFileDWARFDebugMap::FindCompleteObjCDefinitionTypeForDIE(
void SymbolFileDWARFDebugMap::FindTypes(const TypeQuery ,
TypeResults ) {
std::lock_guard guard(GetModuleMutex());
+ Progress progress(
+
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
+clang::Decl const *From) {
+ assert(From &&
+
@@ -1240,7 +1241,13 @@ TypeSP
SymbolFileDWARFDebugMap::FindCompleteObjCDefinitionTypeForDIE(
void SymbolFileDWARFDebugMap::FindTypes(const TypeQuery ,
TypeResults ) {
std::lock_guard guard(GetModuleMutex());
+ Progress progress(
+
https://github.com/adrian-prantl commented:
Nice!
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
+clang::Decl const *From) {
+ assert(From &&
+
https://github.com/adrian-prantl edited
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1240,7 +1241,13 @@ TypeSP
SymbolFileDWARFDebugMap::FindCompleteObjCDefinitionTypeForDIE(
void SymbolFileDWARFDebugMap::FindTypes(const TypeQuery ,
TypeResults ) {
std::lock_guard guard(GetModuleMutex());
+ Progress progress(
+
Michael137 wrote:
Example of what the DIE parsing progress looks like:
https://github.com/llvm/llvm-project/assets/14071464/bd589ddd-c933-4e14-a380-f4db177e33d4
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Michael Buch (Michael137)
Changes
This is an attempt at displaying the work that's being done by LLDB when
waiting on type-completion events, e.g., when running an expression. We add
three new progress reports (across three commits):
1.
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/91452
This is an attempt at displaying the work that's being done by LLDB when
waiting on type-completion events, e.g., when running an expression. We add
three new progress reports (across three commits):
1. When
34 matches
Mail list logo
