[Lldb-commits] [PATCH] D51578: DWARFConcatenatingDataExtractor for D32167
Jan Kratochvil via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Sun Oct 21 10:47:21 PDT 2018
jankratochvil updated this revision to Diff 170342.
jankratochvil added a comment.
Herald added a subscriber: arphaman.
Patch `concat` = original posting with `DWARFConcatenatingDataExtractor` used only for `.debug_info`(+`.debug_types`) section. download <https://people.redhat.com/jkratoch/concat.patch>
Patch `concat2` = used `DWARFDataExtractor` with integrated concatenation for all DWARF sections. download <https://people.redhat.com/jkratoch/concat2.patch>
master real=0.996s user=14.744s sys=1.050s
concat real=0.994s user=15.524s sys=1.117s
concat2 real=1.001s user=15.580s sys=1.334s
`concat` vs. `concat2` benchmark difference was mostly a measurement error. It is now 5% slowdown compared to trunk - even for former `concat` which I do not understand now, I will investigate it more as my original measured slowdown was just 1% before.
`concat2` sometimes needs to cast `DWARFDataExtractor` to `DataExtractor` by `.AsDataExtractor()` as some functions expected a contiguous block of memory. That is a method applicable only for non-`.debug_info` sections (it would assert on `.debug_info`). It needs to be called as `DWARFDataExtractor` can no longer inherit `DataExtractor`. I did not use `operator DataExtractor &` as it could accidentally by applied to `.debug_info` which may be difficult to catch when not tested with `-fdebug-types-section`.
`DataExtractorConcat` is a separate class but it is never used separately without `DWARFDataExtractor` inheriting it.
Greg, do you mean it somehow way or do I miss something? Personally I may like a bit more `concat` but then the patch size is almost the same for both.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 39516 bytes
Desc: not available
More information about the lldb-commits