tberghammer added a comment.
I decided to go with your approach primarily because I tried it out with lower
number of threads and it performed marginally better (~10%) in that case
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-c
clayborg added a comment.
I would venture to say we should optimize for C++ since those libraries tend to
be larger, but I will leave the decision to you.
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http
tberghammer removed rL LLVM as the repository for this revision.
tberghammer updated this revision to Diff 38128.
tberghammer added a comment.
I tried out the implementation you suggests and made some measurements. The
difference between the 2 implementation when attaching to LLDB is negligible
clayborg added a comment.
See inlined comments.
Comment at:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2087-2088
@@ +2086,4 @@
+results.emplace_back(TaskPool::AddTask(parser_fn, cu_idx));
+for (auto& f : results)
+f.wait();
+
tberghammer added a comment.
I reverted this change, as it caused some race condition, but see my comment
inline.
Comment at:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2087-2088
@@ +2086,4 @@
+results.emplace_back(TaskPool::AddTask(parser_fn, c
clayborg added inline comments.
Comment at:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2087-2088
@@ +2086,4 @@
+results.emplace_back(TaskPool::AddTask(parser_fn, cu_idx));
+for (auto& f : results)
+f.wait();
+
S
This revision was automatically updated to reflect the committed changes.
Closed by commit rL250821: Make dwarf parsing multi-threaded (authored by
tberghammer).
Changed prior to commit:
http://reviews.llvm.org/D13662?vs=37353&id=37866#toc
Repository:
rL LLVM
http://reviews.llvm.org/D13662
clayborg added a comment.
BTW: if we can modify clang to produce the Apple accelerator tables, we won't
need to do any of this indexing which will really speed up debugging! We only
produce the Apple accelerator tables on Darwin, but we could on other systems.
There is also a new version of the
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Just saw that patch, so this looks good then pending the other patch.
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-commi
tberghammer added a comment.
Please see http://reviews.llvm.org/D13727
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Missing the TaskPool.h and TaskPool.cpp files?
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-commits@lists.llvm
tberghammer updated this revision to Diff 37353.
tberghammer added a comment.
Herald added a subscriber: iancottrell.
Use the new ThreadPool class and make the Append+Finalize stage parallel.
http://reviews.llvm.org/D13662
Files:
source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
source/Plugins/
zturner added a comment.
You can probably limit the number of threads portably by using a sempahore that
blocks after it's been acquired `std::thread::hardware_concurrency()` times.
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-
zturner added a comment.
fwiw, I know for a fact on Windows the number of threads are limited. So
you're good to go here, can't speak for other platforms.
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
clayborg added a comment.
std::async is fine as long as it doesn't blow out the threads on any supported
systems. We should also test doing multiple std::async calls in different
places in some test only code to make sure if we run 4 std::async calls at once
on different threads that we don't e
zturner added a subscriber: zturner.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2074
@@ +2073,3 @@
+
+std::lock_guard lock(index_mutex);
+m_function_basename_index.Append(function_basename_index);
Every one of t
tberghammer added a comment.
It is depending on the implementation of std::async what AFAIK isn't defined by
the standard, but I would expect that a decent stl implementation will create a
reasonable number of threads (in some sense).
While developing/testing the code (with ~3000 CU in a Symbol
clayborg added a comment.
If you have 1000 compile units, will this spawn 1000 threads simultaneously?
http://reviews.llvm.org/D13662
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commi
tberghammer created this revision.
tberghammer added reviewers: labath, clayborg.
tberghammer added a subscriber: lldb-commits.
Make dwarf parsing multi-threaded
Loading the debug info from a large application is the slowest task
LLDB do. This CL makes most of the dwarf parsing code multi-threade
19 matches
Mail list logo
