If it's trying to create 4 billion non-existing elements per vector, there's probably no need to sample. It explains the lost time pretty well.
Let me know if you want me to file a bug. I'm encountering other issues, for instance sometimes trying to `p some_name`, I get: error: Couldn't materialize struct: size of variable some_name disagrees with the ValueObject's size Errored out in Execute, couldn't PrepareToExecuteJITExpression Perhaps lldb simply isn't production ready for non-OSX platforms? On Mon, Nov 4, 2013 at 2:14 PM, Enrico Granata <[email protected]> wrote: > Replies inlined > > Enrico Granata > 📩 egranata@.com > ☎️ 27683 > > On Nov 4, 2013, at 1:48 PM, Dun Peal <[email protected]> wrote: > > In my case, it's a vector of vectors of pairs of ints, i.e. > vector<vector<pair<int,int>>>. > > I'm not sure what "a sample of lldb taken while it's sitting there" means. > Sorry, I'm an LLVM newbie. > > > If you are on OSX, it simply means typing *sample lldb* at a bash prompt > :) > It will periodically look at the state of LLDB and generate a report of > what is most likely taking up all that time > > On Linux/Windows/.. I suppose there are equivalent facilities. Google is > your friend. A process sample has nothing to do with LLVM specifically. > > I have reproduced the problem with minimal code, posted below. Two > interesting observations: > > 1) For some reason, lldb prints each vector<pair<int,int>> as: > > [0] = size=4294967295 { > [0] = (first = 0, second = 1) > [1] = (first = 1, second = 2) > [2] = (first = 2, second = 3) > [3] = (first = 3, second = 4) > ... > } > > Since each of those vectors is exactly 4 pairs, it is printed in its > entirety, so I'm not sure why there's an ellipsis there. > > > It looks like something is wrong with this data structure and we believe > its size to be the large number > That value is not just a placeholder, it’s how many elements LLDB actually > thinks are in the vector! > Most likely we end up realizing those are not valid and so we omit > printing them, but we still believe they exist, and since you likely asked > to see all of them, we are trying to create 4 billion elements and failing. > Here your 300 seconds > Why we end up with malformed data like that is an interesting question. I > will try to repro > > 2) The times I quoted above are surprisingly preserved with this sample > code. For example, printing the first 256 elements is still about 8 > seconds. Printing all 300 elements, which is only about 20% more, takes 300 > seconds, i.e. almost x40 the time! Curious. > > #include <iostream> > #include <vector> > > using namespace std; > > int main() { > vector<vector<pair<int,int> > > vec; > for (int i=0; i < 300; ++i) { > vector<pair<int,int> > v; > for (int j=0; j < 4; ++j) { > v.push_back(make_pair(i+j, i+j+1)); > } > vec.push_back(v); > } > return 0; // to reproduce, put a breakpoint in this line, and `p vec` > } > > > On Mon, Nov 4, 2013 at 12:49 PM, Enrico Granata <[email protected]>wrote: > >> Yes please. Possibly with a sample of lldb taken while it's sitting there. >> From your email, it sounds like the repro case is just a vector of pairs >> of int and int, with about 400 elements. Is that all? >> >> Sent from the iPhone of >> *Enrico Granata* <egranata@🍎.com> >> >> On Nov 4, 2013, at 12:42 PM, Dun Peal <[email protected]> wrote: >> >> Thanks! This works, though surprisingly slow; I just printed a >> vector<vector<pair<int,int>>> of 384 elements, and it blocked for about 390 >> seconds (6:30 minutes!) before rendering. >> >> The print only blocks for about 8 seconds when rendering the first 256 >> elements (i.e. without the settings change). >> >> This is LLDB 3.4 from the LLVM aptitude repo, running on a high end >> Xubuntu Linux 13.04 developer workstation. >> >> This is obviously a major usability issue for me with LLDB. Should I file >> a bug for this? >> >> >> On Mon, Nov 4, 2013 at 10:05 AM, Greg Clayton <[email protected]> wrote: >> >>> (lldb) settings show target.max-children-count >>> target.max-children-count (int) = 256 >>> (lldb) settings set target.max-children-count 10000 >>> >>> >>> You can then add this line to your ~/.lldbinit file if you want the >>> setting to always be increased. >>> >>> >>> On Nov 3, 2013, at 7:57 PM, Dun Peal <[email protected]> wrote: >>> >>> > Hi, >>> > >>> > When I do: >>> > >>> > (lldb) p some_vector >>> > >>> > It seems LLDB only actually prints the first 256 values. How do I get >>> it to print the entire vector? >>> > >>> > Thanks, D. >>> > _______________________________________________ >>> > lldb-dev mailing list >>> > [email protected] >>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> > >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
