clayborg added a comment. In https://reviews.llvm.org/D32757#743669, @scott.smith wrote:
> In https://reviews.llvm.org/D32757#743657, @clayborg wrote: > > > In https://reviews.llvm.org/D32757#743567, @scott.smith wrote: > > > > > IMO, this is a simpler interface than TaskRunner. Also, after this, > > > there are no users of TaskRunner left. Should I just delete them? > > > > > > I think you might not have understood TaskRunner's real benefits. It is > > smart in the way it runs things: it lets you run N things and get each item > > **as soon as it completes**. The TaskMap will serialize everything. So if > > you have 100 items to do and item 0 takes 200 seconds to complete, and > > items 1 - 99 take 1ms to complete, you will need to wait for task 0 to > > complete before you can start parsing the data. This will slow down the > > DWARF parser if you switch over to this. TaskRunner should not be deleted > > as it has a very specific purpose. Your TaskMap works fine for one case, > > but not in the other. > > > That may provide a benefit on machines with a few cores, but doesn't really > help when you have 40+ cores. Granted, the average laptop has 4 cores/8 > hyperthreads. It is no different on any machine with any number of cores. TaskRunner will be faster in all cases for the second DWARF loop. It is also nice to be able to consume the information as it comes in, so TaskRunner is needed. I do like the TaskMap idea to make things batch-able so I think they both add value. > > >>> I did this change to help parallel symbol demangling (to come in a separate >>> patch). Rather than have the symbol demangler use batching, etc, I thought >>> it should be a higher level function. >> >> Make sure this is a win before switching demangling over to using threads. I >> tried to improve performance on demangling before and I got worse >> performance on MacOS when we tried it because all of the malloc contention >> and threading overhead. > > It is on my machine, but maybe not on other machines. That would be > unfortunate. I'm guessing I shouldn't add go ahead and add jemalloc/tcmalloc > to work around poor a MacOS malloc? haha. lol. If it does improve things and if it integrates nicely with all of the malloc tools on MacOS, I wouldn't be opposed. I don't know much about jemalloc/tcmalloc, but if there are perf wins to be had that don't hose over the malloc zone/block iterations I am all for it! Repository: rL LLVM https://reviews.llvm.org/D32757 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
