Enum to ints or strings.

[littlefreak3000]

The DateTime to Date conversion sped things up so much. Before I was sending ticks and then converting them to Dates as this was faster then dealing with DateTime on the JS side. I am using ClearScript currently as a way for my users to inject custom functions into a processing loop. So I am passing an object to a function millions of time. So I've been testing all kinds of optimizations and what is faster.

Currently doing anything with enums it is faster to run utf8json convert the object to a json string (1000+ characters) and then call JSON.parse on the JS side to get my object. This puts the enums into strings. Its a shame as if I am doing anything other then dealing with enums then the standard way is 33% faster. I have read all the previous issues involving enums and have tried all the suggested options, but they all require crossing the JS/CS barrier and it seems there is a heavy performance hit anytime that is done. And that 33% value is only based on me making 1 switch statement for 1 enum if I wanna do that for multiple different enums who knows if those performance hits stack.

I dug deep enough to find when DateTime conversion was added and found the code that did it. Seems like it would be possible to do something similar to enums with a int cast. String casting could be a little harder, but some users might like that. A lot has happened since that conversion was added though and I can't seem to find where it is located in the current code base. If someone would point me in the right direction as the file it was originally in doesn't exist in the latest build. I'd gladly try my hand at implementing it as for my system it would be worth the billable hours to do so and I'll submit a PR when done. Though I bet someone more familiar with the code base might be able to implement it too. If this is considered out of scope for the project I would completely understand that as you have your solutions for enums already and they do work. I don't know how many people are concerned about performance like I might be.

Hell for what I am using this for even if you didn't accept the PR I'd happily patch each new release for myself. So again anyone who could point me to where those functions are in the current code base I'd appreciate it.

[ClearScriptLib]

Hello @littlefreak3000,

Currently doing anything with enums it is faster to run utf8json convert the object to a json string (1000+ characters) and then call JSON.parse on the JS side to get my object. This puts the enums into strings. Its a shame as if I am doing anything other then dealing with enums then the standard way is 33% faster. I have read all the previous issues involving enums and have tried all the suggested options, but they all require crossing the JS/CS barrier and it seems there is a heavy performance hit anytime that is done.

That's surprising, as ClearScript caches enum tokens in native code to avoid jumping to the managed side for token retrieval. Can you give us an idea about how you expose and access enums in script code (without JSON serialization)? Perhaps a minimal code sample?

Thanks!

[littlefreak3000]

Yea so initialize my V8 Engine like this:

          engine = new(V8ScriptEngineFlags.EnableStringifyEnhancements | V8ScriptEngineFlags.EnableDateTimeConversion | 
           V8ScriptEngineFlags.UseCaseInsensitiveMemberBinding) { UndefinedImportValue = null };

            engine.Execute(File.ReadAllText(script));
            engine.Execute(File.ReadAllText("./ScriptEngine/JSEngine.js"));
            engine.AddHostType(typeof(AltResolution));

Where JSEngine.js is my systems js code and script is the one submitted by users.
AltResolution is the enum in question. The script submitted by the user has a function called loop that is called by my system. And for this test where I saw a 30% lost that function looked like this:

function Loop(ts, p, { map }) {

    if (!map.has(p.ID)) {
        map.set(p.ID, { resUnk: 0, res100: 0, res25: 0 });
    }

    switch (p.AltResolution) {
        case AltResolution.ResUnknown:
            map.get(p.ID).resUnk++;
            break;
        case AltResolution.Res100Feet:
            map.get(p.ID).res100++;
            break;
        case AltResolution.Res25Feet:
            map.get(p.ID).res25++;
            break;
    }
}

p is the object I am passing from C# every call. So if I wrap Loop in another function call like this:

function __Loop__(ts, json) {
    Loop(ts, JSON.parse(json), __state__);
}

That parses a json version of the object instead of passing the object from C# directly to the loop function. It turns out to be faster but only when enums are involved. For example if the user doesnt require accessing any kind of enum its faster to not do json parsing. I have considered just removing all enum from my data set and just do them using constants but honestly that be a real pain because I am using ToString to write them to a human readable file and this code inject is only a small subset of the system so to make that kind of change just to improve its performance doesnt seem smart.

To give you my metric. I am running a test that calls this function 1,234,080 with different values of p (this is only a 5 minute data set run when people actually use the system its days, weeks or months). So test without enums I run a similar switch statement on a int value and put the value in one of 3 buckets (so practically same code no enum) it take 24 seconds to run on average (100 tests). Now I run the exact code above using the enum and it take 35 seconds to run on average (100 tests). If I do JSON.parse method and use the enums as if they were strings (EX: Case: "ResUnkown") it runs at 30 seconds on average (100 tests). The issue with this is this 30second cost for the JSON convert is across the board so its wasteful if the users script doesnt use an enum but is faster if they do.

Now I use to convert ts (C# datetime) to js Date just like how I am doing that JSON.parse. But since the feature for DateTime conversions was added I no longer have to and it is much faster then my original method. So if the same could be done for enums with similar effect it would be great.

[ClearScriptLib]

Hi @littlefreak3000,

Generally speaking, if an object is just data – that is, if script code requires only a snapshot of the object's properties rather than "live" access to the actual object instance, then JSON serialization is something we recommend, especially if the object is a large collection or has many properties. There's simply no faster way to transfer structured data of nontrivial size across the host-script boundary.

Nevertheless, we've run your test code to compare its performance with enums and integers. Here's our test program:

public enum AltResolution { ResUnknown, Res100Feet, Res25Feet }
public class Thing {
    private static readonly Random random = new Random();
    public int ID { get; } = random.Next();
    public int AltResolutionInt { get; } = random.Next(3);
    public AltResolution AltResolution => (AltResolution)AltResolutionInt;
}
public static class TestApp {
    public static void Main() {
        var enumTotalTime = TimeSpan.Zero;
        var intTotalTime = TimeSpan.Zero;
        var things = Enumerable.Range(0, 200000).Select(_ => new Thing()).ToList();
        const string enumSource = @"
            function (ts, p, { map }) {
                const id = p.ID;
                if (!map.has(id)) map.set(id, { resUnk: 0, res100: 0, res25: 0 });
                switch (p.AltResolution) {
                    case AltResolution.ResUnknown: map.get(id).resUnk++; break;
                    case AltResolution.Res100Feet: map.get(id).res100++; break;
                    case AltResolution.Res25Feet: map.get(id).res25++; break;
                }
            }
        ";
        const string intSource = @"
            function (ts, p, { map }) {
                const id = p.ID;
                if (!map.has(id)) map.set(id, { resUnk: 0, res100: 0, res25: 0 });
                switch (p.AltResolutionInt) {
                    case 0: map.get(id).resUnk++; break;
                    case 1: map.get(id).res100++; break;
                    case 2: map.get(id).res25++; break;
                }
            }
        ";
        RunTest(things, enumSource);  // warmup
        RunTest(things, intSource);   // warmup
        for (var iteration = 1;; ++iteration) {
            var enumTime = RunTest(things, enumSource);
            var intTime = RunTest(things, intSource);
            enumTotalTime += enumTime;
            intTotalTime += intTime;
            var enumAverage = enumTotalTime.TotalSeconds / iteration;
            var intAverage = intTotalTime.TotalSeconds / iteration;
            var intSpeedup = (enumAverage - intAverage) / enumAverage * 100;
            Console.WriteLine(
                "Iteration {0} - Enum: {1:F2}s ({2:F2}s avg), Int: {3:F2}s ({4:F2}s avg)), Int Speed-Up: {5:F2}% avg",
                iteration, enumTime.TotalSeconds, enumAverage, intTime.TotalSeconds, intAverage, intSpeedup
            );
        }
    }
    private static TimeSpan RunTest(List<Thing> things, string source) {
        var time = RunTestWorker(things, source);
        GC.Collect();
        GC.WaitForPendingFinalizers();
        return time;
    }
    private static TimeSpan RunTestWorker(List<Thing> things, string source) {
        using (var engine = new V8ScriptEngine()) {
            engine.AddHostType(typeof(AltResolution));
            var func = (ScriptObject)engine.Evaluate("(" + source + ")");
            var ts = new object();
            var state = engine.Evaluate("({ map: new Map() })");
            var sw = Stopwatch.StartNew();
            foreach (var thing in things) func.InvokeAsFunction(ts, thing, state);
            return sw.Elapsed;
        }
    }
}

After a large number of iterations, our test hardware shows an average speed-up of around 6.5% for the integer version. That's likely due to the slightly more expensive marshaling of p.AltResolution as well as unmanaged callouts for the AltResolution members. That's in line with our expectations.

One way to improve performance without sacrificing type safety is to expose enum types as native objects. Consider the following:

public static class ScriptEngineExtensions {
    public static void AddFastEnumType<T>(this ScriptEngine engine) where T : struct {
        engine.AddFastEnumType<T>(typeof(T).Name);
    }
    public static void AddFastEnumType<T>(this ScriptEngine engine, string name) where T : struct {
        dynamic obj = engine.Script.Object();
        var names = Enum.GetNames(typeof(T));
        var values = Enum.GetValues(typeof(T));
        for (var i = 0; i < names.Length; ++i) obj[names[i]] = values.GetValue(i);
        engine.Script[name] = obj;
    }
}

If we now replace engine.AddHostType(typeof(AltResolution)) with engine.AddFastEnumType<AltResolution>(), the enum version speeds up to within about 3.3%.

If that still not good enough, there are other things you could do. For example, instead of passing your objects directly to script code, you could pass façades that don't use enums at all. Also, again, there's nothing wrong with JSON serialization if your goal is to push a lot of data into the script engine, and many applications do just that.

But since the feature for DateTime conversions was added I no longer have to and it is much faster then my original method. So if the same could be done for enums with similar effect it would be great.

The problem is that enum-to-integer conversion is unidirectional. Script code that receives an enum in integer form couldn't use it as an argument for a parameter of the enum type. The conversion you're proposing would break the strong typing that .NET requires for correct method binding and generic method construction.

Please send any additional thoughts or questions our way!

Thanks!

[littlefreak3000]

I have implemented this and I am seeing better execution times. I added to MarhalToScript:

            if (engineFlags.HasFlag(V8ScriptEngineFlags.EnableEnumConversionInt) && (obj is Enum))
            {
                obj = (int)obj;
            }

            if (engineFlags.HasFlag(V8ScriptEngineFlags.EnableEnumConversionString) && (obj is Enum))
            {
                obj = obj.ToString();
            }

I also tested just returning right out of the if instead of setting the value to obj, and it worked. Is there a reason not to do this. I see at the end of the function it is wrapped in a HostItem is this needed? Would it be better to do something like:

            if (engineFlags.HasFlag(V8ScriptEngineFlags.EnableEnumConversionInt) && (obj is Enum))
            {
                return HostItem.Wrap(this, (int)obj, flags);
            }

Obviously there is a lot of checks in this function and the function is ran for every variable passing the boundary so exiting as soon as you know the answer is best. But you dont bother wrapping bigintegers or datetime etc so is there harm in not wrapping an int or string?

Thanks I'll be preparing a PR soon enough.