An interpreter for the Lua language, written entirely in C# for the .NET, Mono, Xamarin and Unity3D platforms, including handy remote debugger facilities.
For our uses of moonsharp, we have some strong controls forcing sandboxing and total execution cycles/wall time constraints. These include and require us to attach a debugger to every script instance we create (and to create thousands of new script instances, loading our whole lua library each time). As one might guess, this means we strain some odd hot-paths that normally aren't much of a concern.
This specific patch has the Script.SignalByteCodeChange() private function check if the debugger actually even cares about bytecode at that point in time via GetDebuggerCaps().
I am willing to discuss other options, since this does mean there isn't a simple way for the debugger to change its mind after everything has already loaded. We employ either two work arounds to this issue:
Simply load any no-op Lua source such that a new Signal (and thus new Caps() check) is sent which then does feed the debugger. This is our method when we know ahead of time (eg when developer debugging not just part of our sandboxing constraints)
In our case we can simply re-initialize the entire M# Script instance at a higher level that is giving us problems and re-wind and re-run with a more capable tracing/logging debugger for post-mortem analysis. This is our preferred method when in-production SREs are thrown to add more detail for logging.
Note: Still having work figure out how to OK publishing our full fork and internal patches such that proper PRs could be submitted since we don't use github (or any public git service). For now going through our older .PATCH process for the smaller things that were real nice to haves.
From 92e6257512828b1a195d9060e5799c2fa6899484
From: Eric Driggers <EricDriggers@toppanmerrill.com>
Subject: [PATCH] Debugger: Only signal byte/source changes if DebuggerCaps says to.
Performance numbers via ORE at 32 cores: 80% of total CPU vs now of 17% of total CPU.
---
src/MoonSharp.Interpreter/Script.cs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/MoonSharp.Interpreter/Script.cs b/src/MoonSharp.Interpreter/Script.cs
index 6e3bb11..faf42d2 100755
--- a/src/MoonSharp.Interpreter/Script.cs
+++ b/src/MoonSharp.Interpreter/Script.cs
@@ -137,7 +137,7 @@ namespace MoonSharp.Interpreter
private void SignalByteCodeChange()
{
- if (m_Debugger != null)
+ if (m_Debugger != null && (m_Debugger.GetDebuggerCaps() & DebuggerCaps.CanDebugByteCode) != 0)
{
m_Debugger.SetByteCode(m_ByteCode.Code.Select(s => s.ToString()).ToArray());
}
@@ -145,7 +145,7 @@ namespace MoonSharp.Interpreter
private void SignalSourceCodeChange(SourceCode source)
{
- if (m_Debugger != null)
+ if (m_Debugger != null && (m_Debugger.GetDebuggerCaps() & DebuggerCaps.CanDebugSourceCode) != 0)
{
m_Debugger.SetSourceCode(source);
}
--
For our uses of moonsharp, we have some strong controls forcing sandboxing and total execution cycles/wall time constraints. These include and require us to attach a debugger to every script instance we create (and to create thousands of new script instances, loading our whole lua library each time). As one might guess, this means we strain some odd hot-paths that normally aren't much of a concern.
This specific patch has the
Script.SignalByteCodeChange()
private function check if the debugger actually even cares about bytecode at that point in time viaGetDebuggerCaps()
.I am willing to discuss other options, since this does mean there isn't a simple way for the debugger to change its mind after everything has already loaded. We employ either two work arounds to this issue:
Note: Still having work figure out how to OK publishing our full fork and internal patches such that proper PRs could be submitted since we don't use github (or any public git service). For now going through our older
.PATCH
process for the smaller things that were real nice to haves.