I haven't been able to reproduce this locally (the console starts up quickly, should I login to the site as well?), but looking at the profile and the source there are several potential performance pitfalls here. The biggest one is that we can ask for the breakpoint positions on a source multiple times (if there are many original sources corresponding to different parts of the generated source), and if any scripts have been GC'ed then each time we will reparse the entire generated source and generate a new batch of scripts to examine. This is expensive, and can generate a lot of garbage for the GC to clean up. It's easy to memoize this computation and we should do that.
Beyond that, there is another pitfall where calling dbg.findScripts() with a line number in the query will trigger delazification of every script in the source, which will also be really expensive on a huge generated source. We don't use a line number in the query when getting breakpoint positions, but we do in other places, and I can't tell if those are being called here (it would be really sweet to have a web replay recording associated for the profile, so the page's behavior can be examined in minute detail).
In general, the source actor isn't very well optimized for dealing with huge generated sources. Every time we have to get some of the scripts in the source we ask the debugger for them, and every time we do that the debugger has to scan every script in the realm. It would be much nicer if the source actor could do this query once, and index the results so that it can quickly find scripts in certain parts of the source. I'll see if I can do that, which would address the two points above as well.