Debugger causes 100X slowdown

[garfieldnate]

The debugger registers quite a few event handlers, which are then called synchronously while an agent is running. These handlers send data from the Soar kernel over the SML bridge, meaning over the network and through an XML translation process both ways.

The development cycle for an agent generally involves having the debugger open at all times, and the slowdown can be quite significant.

From John:

With the debugger, it takes ~5500 seconds in real-time (73 kernel) to run my example scenario in Thor-Soar (116,733 decisions). Without the debugger, the decisions are the same, but they take 39 seconds real time (22 kernel). >100 times faster real time (which I care about!).

Investigate why exactly the debugger is so slow and ameliorate the slowdown. If the slowdown is unavoidable, then something like a pause button that temporarily disconnects the debugger would probably suffice.

[scijones]

This might confuse things because of the janky setup I was using, but it might offer clues.

I was running an agent with attached debugger all within windows subsystem for linux and found that there was much less slowdown.

[garfieldnate]

Bob also reported:

we tried running Soar with just SML (an SML script that loaded things and then ran Soar for x decisions) and it was Debugger-ish slow. So the issue may be more related to the socket connection than the Debugger per se. (Running Soar without SML directly from DroneSoar was blazingly fast but did require changes to DroneSoar to start Soar running and, for batch, we also had the sim exit on Soar interrupt after x seconds).