<div dir="ltr"><div class="gmail_default" style="font-size:small">Speaking more generally, can evaluating an expression with no side effects affect the outcome of subsequent evaluations? I.e, is it possible for the expression evaluation X to produce different results in the following scenarios?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Scenario 1: <set of instructions A> <expression evaluation with no side effects> <set of instructions B> <expression evaluation X><br>Scenario 2: <set of instructions A> <set of instructions B> <expression evaluation X><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 2:52 PM Guilherme Andrade <<a href="mailto:guiandrade@google.com">guiandrade@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks for looking into this, Jason. I ended up realizing that it isn't about the number of evaluations; it is the exact location of the breakpoints that matters.<br><br>I'm being able to consistently reproduce this by having two breakpoints (A and B) inside the same function, but B being inside the scope of a for loop that defines a couple extra variables. The first evaluation of 'undefinedVariable' at breakpoint A generates the following FindExternalLexicalDecls calls:<br><br><font color="#0000ff">FindExternalLexicalDecls[5] on (ASTContext*)000001566104F030 in 'Type0' (CXXRecordDecl*)0000015668964438<br>FindExternalLexicalDecls[6] on (ASTContext*)000001566104F030 in 'Type6' (CXXRecordDecl*)0000015668961BA8<br>FindExternalLexicalDecls[7] on (ASTContext*)000001566104F030 in 'Type7' (CXXRecordDecl*)0000015668961A68<br>FindExternalLexicalDecls[8] on (ASTContext*)000001566104F030 in 'Type8' (CXXRecordDecl*)0000015674F56208<br>FindExternalLexicalDecls[9] on (ASTContext*)000001566104F030 in 'Type9' (ClassTemplateSpecializationDecl*)0000015674F56CD0<br>FindExternalLexicalDecls[10] on (ASTContext*)000001566104F030 in 'Type10' (CXXRecordDecl*)0000015668964300<br>FindExternalLexicalDecls[11] on (ASTContext*)000001566104F030 in 'Type10' (CXXRecordDecl*)0000015668964300<br>FindExternalLexicalDecls[12] on (ASTContext*)000001566104F030 in 'Type0' (CXXRecordDecl*)0000015668964438<br>FindExternalLexicalDecls[13] on (ASTContext*)000001566104F030 in 'Type11' (EnumDecl*)0000015674F62778</font><br><br>Then, the evaluation at breakpoint B generates:<br><br><font color="#0000ff">FindExternalLexicalDecls[19] on (ASTContext*)000001F1F6275320 in 'Type0' (CXXRecordDecl*)000001F1EA798868<br></font><font color="#ff9900">FindExternalLexicalDecls[20] on (ASTContext*)000001F1F6275320 in 'Type1' (CXXRecordDecl*)000001F1EA799098<br>FindExternalLexicalDecls[21] on (ASTContext*)000001F1F6275320 in 'Type2' (ClassTemplateSpecializationDecl*)000001F1EA7A0D50<br>FindExternalLexicalDecls[22] on (ASTContext*)000001F1F6275320 in 'Type3' (CXXRecordDecl*)000001F1EA79D818<br>FindExternalLexicalDecls[23] on (ASTContext*)000001F1F6275320 in 'Type4' (CXXRecordDecl*)000001F1EA79D548<br>FindExternalLexicalDecls[24] on (ASTContext*)000001F1F6275320 in 'Type5' (CXXRecordDecl*)000001F1EA7A2A08</font><br><font color="#0000ff">FindExternalLexicalDecls[25] on (ASTContext*)000001F1F6275320 in 'Type6' (CXXRecordDecl*)000001F1EA7BB368<br>FindExternalLexicalDecls[26] on (ASTContext*)000001F1F6275320 in 'Type7' (CXXRecordDecl*)000001F1EA7BB228<br>FindExternalLexicalDecls[27] on (ASTContext*)000001F1F6275320 in 'Type8' (CXXRecordDecl*)000001F1F68B9088<br>FindExternalLexicalDecls[28] on (ASTContext*)000001F1F6275320 in 'Type9' (ClassTemplateSpecializationDecl*)000001F1F68B2AC0<br>FindExternalLexicalDecls[29] on (ASTContext*)000001F1F6275320 in 'Type10' (CXXRecordDecl*)000001F1EA798730<br>FindExternalLexicalDecls[30] on (ASTContext*)000001F1F6275320 in 'Type10' (CXXRecordDecl*)000001F1EA798730<br>FindExternalLexicalDecls[31] on (ASTContext*)000001F1F6275320 in 'Type0' (CXXRecordDecl*)000001F1EA798868<br>FindExternalLexicalDecls[32] on (ASTContext*)000001F1F6275320 in 'Type11' (EnumDecl*)000001F1F68CB3E0</font><br>FindExternalLexicalDecls[33] on (ASTContext*)000001F1F6275320 in 'Type12' (CXXRecordDecl*)000001F1E2351F48<br><br>And the subsequent evaluations at breakpoint A, which are slower, produce:<br><br><font color="#0000ff">FindExternalLexicalDecls[91] on (ASTContext*)000001566104F030 in 'Type0' (CXXRecordDecl*)000001566895C3B8<br></font><font color="#ff9900">FindExternalLexicalDecls[92] on (ASTContext*)000001566104F030 in 'Type1' (CXXRecordDecl*)000001566895CBE8<br>FindExternalLexicalDecls[93] on (ASTContext*)000001566104F030 in 'Type2' (ClassTemplateSpecializationDecl*)00000156689678D0<br>FindExternalLexicalDecls[94] on (ASTContext*)000001566104F030 in 'Type3' (CXXRecordDecl*)0000015668964398<br>FindExternalLexicalDecls[95] on (ASTContext*)000001566104F030 in 'Type4' (CXXRecordDecl*)00000156689640C8<br>FindExternalLexicalDecls[96] on (ASTContext*)000001566104F030 in 'Type5' (CXXRecordDecl*)0000015674F608B8</font><br><font color="#0000ff">FindExternalLexicalDecls[97] on (ASTContext*)000001566104F030 in 'Type6' (CXXRecordDecl*)0000015674F731B8<br>FindExternalLexicalDecls[98] on (ASTContext*)000001566104F030 in 'Type7' (CXXRecordDecl*)0000015674F73078<br>FindExternalLexicalDecls[99] on (ASTContext*)000001566104F030 in 'Type8' (CXXRecordDecl*)0000015674F7B278<br>FindExternalLexicalDecls[100] on (ASTContext*)000001566104F030 in 'Type9' (ClassTemplateSpecializationDecl*)0000015674F78CF0<br>FindExternalLexicalDecls[101] on (ASTContext*)000001566104F030 in 'Type10' (CXXRecordDecl*)000001566895C280<br>FindExternalLexicalDecls[102] on (ASTContext*)000001566104F030 in 'Type10' (CXXRecordDecl*)000001566895C280<br>FindExternalLexicalDecls[103] on (ASTContext*)000001566104F030 in 'Type0' (CXXRecordDecl*)000001566895C3B8<br>FindExternalLexicalDecls[104] on (ASTContext*)000001566104F030 in 'Type11' (EnumDecl*)0000015674F81510</font><br><br>The FindExternalVisibleDecls entries remain the same among all evaluations at breakpoint A.<br><br>So, Jim, if symbols are getting added at B
or types are being completed, then the extra FindExternalLexicalDecls calls for Type1-5 is intended behavior?<br><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 7:04 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are any sources for symbols getting added to the process as you go along, like new shared library loads? You are asking for a non-existent name, so every new source of debug info is a new place to look.<br>
<br>
It's also possible that we are completing some types during the course of the expression evaluation, and then the newly completed types become themselves new places to look for this non-existent name.<br>
<br>
You can see what is getting looked up by turning in the expression log (log enable lldb expr) then looking for the FindExternalVisibleDecls entries.<br>
<br>
Jim<br>
<br>
<br>
> On Jul 8, 2019, at 3:33 PM, Jason Molenda via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hm, that's interesting.<br>
> <br>
> I tried running a debug lldb on /bin/ls. then I attached from another lldb. I put a breakpoint on CommandObjectTargetModulesLookup::DoExecute and resumed execution. In the debuggee lldb, I did<br>
> <br>
> tar mod loo -a 0<br>
> <br>
> <br>
> and auto-repeated return so the same command would be executed over and over.<br>
> <br>
> In the debugger lldb, I tried adding a command to the breakpoint,<br>
> <br>
> br comm add <br>
> p does_not_exist<br>
> DONE<br>
> <br>
> and continuing - after a couple dozen times, I didn't see a slowdown. I tried adding a breakpoint condition,<br>
> <br>
> br mod -c 'doesNotExist == 1' 1<br>
> <br>
> and continuing, and didn't see a slowdown after a few dozen repetitions.<br>
> <br>
> I'm on macOS using .o file DWARF debugging.<br>
> <br>
> I'm sure there's a bug here, but it may be more specific to the platform and type of debug info that you're using? It could be that lldb is too small of a project to repo this problem too.<br>
> <br>
> <br>
> <br>
>> On Jul 4, 2019, at 11:38 AM, Guilherme Andrade via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
>> <br>
>> I have two breakpoint inside methods that are called every frame (C++ project using Unreal), and every time one of them is reached, I evaluate one expression (I'm being able to reproduce this using an undefined name, say "undefinedVariable"). After a few iterations (usually tens), the time it takes for LLDB to say that name doesn't exist increases, despite being the same expression, at the same breakpoint and the call stack remaining unchanged.<br>
>> <br>
>> I've noticed that the number of lexical Decl queries and imports conducted by Clang reported in 'Local metrics' increase.<br>
>> <br>
>> They go from:<br>
>> Number of visible Decl queries by name : 29<br>
>> Number of lexical Decl queries : 9<br>
>> Number of imports initiated by LLDB : 15<br>
>> Number of imports conducted by Clang : 827<br>
>> Number of Decls completed : 5<br>
>> Number of records laid out : 2 <br>
>> <br>
>> To:<br>
>> Number of visible Decl queries by name : 29<br>
>> Number of lexical Decl queries : 14<br>
>> Number of imports initiated by LLDB : 15<br>
>> Number of imports conducted by Clang : 1342<br>
>> Number of Decls completed : 5<br>
>> Number of records laid out : 2<br>
>> <br>
>> Also, the number of SymbolFileDWARF operations in the logs jumps from 366 to 406.<br>
>> <br>
>> So, I've got two questions. 1) Is it safe to say that those extra imports and Decl queries are responsible for the performance loss? 2) Why do they happen?<br>
>> <br>
>> Thanks!<br>
>> _______________________________________________<br>
>> lldb-dev mailing list<br>
>> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
> <br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br></blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Guilherme Andrade |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:guiandrade@google.com" target="_blank">guiandrade@google.com</a> |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="https://careers.google.com/locations/waterloo/" target="_blank">Google Waterloo, Canada</a></span></div></div></div>