At this point, performance is good enough for our use-case, no qualms from
me.
On Tue, Jun 14, 2022 at 4:10 PM David Blaikie via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Given the discussion previously in this thread - does anyone have
> particular objections to removing .debug
Hi David
I implemented some optimizations in the form of a specialized parser for
fast AT_ranges scanning and performance is now comparable to lazy
evaluation through .debug_aranges (only marginally worse assuming buffer
cache warmed up). We've since shipped with these optimizations. I have to
do
Thanks for the detailed response David.
On Fri, Apr 9, 2021 at 2:52 PM David Blaikie wrote:
> I'm not suggesting scanning all of .debug_info - only the CU DIE for
> DW_AT_ranges or high/low_pc, then skip to the next CU DIE (via the
> unit header's next unit offset).
>
> It sounded like CU range
Responses inline.
On Fri, Mar 19, 2021 at 9:59 PM David Blaikie wrote:
> On Fri, Mar 19, 2021 at 9:34 AM Samy Al Bahra wrote:
>
[...]
> This is quite old (excuse the formatting) but numbers are here:
>> https://engineering.backtrace.io/2014-09-15-bt-lightweight-backtrace-tool/
>> , search fo
2021 at 2:15 PM Greg Clayton wrote:
>
>
> On Mar 19, 2021, at 9:33 AM, Samy Al Bahra via Dwarf-Discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
> Hi David,
>
> Sorry I'm a bit late to the game. On the value of having .debug_aranges
> and the performance
Hi David,
Sorry I'm a bit late to the game. On the value of having .debug_aranges and
the performance impact:
Our debugger was designed for performance and does end to end lazy
evaluation (down to the DIE). This is quite old (excuse the formatting) but
numbers are here:
https://engineering.backtr
