If it is down to lazy source positions, then what *should* happen is that it would reparse each function at the point that you set the breakpoint as otherwise it wouldn't know where to set it. In that case you would get 1000 function reparses. It shouldn't need to reparse every function each time, because a) it only needs the source positions for the function it's setting the break point on and b) it doesn't need to parse the entire program to do that.
As Leszek says, disabling the feature via the flag would tell you if it's responsible. The code in your gist is just the code to be debugged, but not the code that sets the break points. A repro with just 10 functions should be sufficient to show that it's doing 100 reparses and we can go from there. Thanks, Dan On Tue, 6 Oct 2020 at 09:08, Leszek Swirski <[email protected]> wrote: > This might be lazy source positions forcing a reparse, have you tried > running with --no-enable-lazy-source-positions? > > On Tue, Oct 6, 2020 at 3:23 AM Gunes Acar <[email protected]> wrote: > >> The missing screenshot of the trace can be seen at: Github: >> https://gist.github.com/gunesacar/b8f82266e93fbfda2bf06c573af3caea#gistcomment-3478635 >> >> On Tuesday, October 6, 2020 at 3:15:53 AM UTC+2 Gunes Acar wrote: >> >>> Hi all, >>> >>> For an academic research project, we use Chrome Devtools Protocol to set >>> breakpoints at function returns, and collect function call metadata (stack >>> frames, arguments, timestamps) using a condition script(*). >>> >>> Although the condition script always returns `false` to avoid pausing >>> the debugger, we still observe a significant overhead per "hit" breakpoint. >>> >>> To identify the root cause, we set up tracing and found that >>> *V8.ParseProgram* is called for each "hit" breakpoint. We then logged >>> function events using "*--js-flags=--log-function-events*", which >>> showed that all functions in the debugged script is *fully parsed* >>> (i.e., `function,full-parse,...` event) for each "hit" breakpoint. >>> >>> >>> For example, assume the debugged script contains 10K function >>> definitions, of which only a 100 is called. We observe ~10K*100=~1M >>> function (full-)parse events in the logs, which slows down the process and >>> makes it unfeasible on heavy websites. >>> >>> 1) Is it possible to prevent repeated parsing of the debugged script for >>> each evaluated breakpoint? >>> >>> 2) Could there be an easier and faster way of logging all function calls >>> with the associated stack frames and arguments? Pointers to the relevant >>> code locations would be much appreciated if modifying Chrome/V8 source code >>> is the only way to do that. >>> The trace and test files can be found in this Gist >>> <https://gist.github.com/gunesacar/b8f82266e93fbfda2bf06c573af3caea#file-trace-json> >>> . >>> >>> Thanks so much and stay safe, >>> Gunes >>> >>> PS: None of our breakpoints were actually hit, since the condition >>> script always returns false. Also, the debugged scripts were not modified >>> during the execution through `Debugger.setScriptSource` or by any other >>> means >>> >>> *: Idea from the DuckDuckGo’s Tracker Radar Collector >>> <https://github.com/duckduckgo/tracker-radar-collector/blob/98fa0f5a00016a2d10a43d86e16b38601f7ee387/collectors/APICalls/TrackerTracker.js#L76> >>> >>> >>> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/f3242ed8-a082-4b68-868b-1a18f9d98323n%40googlegroups.com >> <https://groups.google.com/d/msgid/v8-dev/f3242ed8-a082-4b68-868b-1a18f9d98323n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/CAGRskv8nby_co6K6%2Bxcyq-WKVvq4_SodGCczQAH_Wg_oTJ%2BBEg%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAGRskv8nby_co6K6%2Bxcyq-WKVvq4_SodGCczQAH_Wg_oTJ%2BBEg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CALH_77sN_wbzqsJeDq82eyactH%3D0Xq%3DYdbfHD4T-Fr0YD%2Byiew%40mail.gmail.com.
