High speed efficiency and performance.

[konethmelathil]

My understanding is that performance is better when

1. Not using variables in maps.
2. Variables exist only one level deep in a structure

Are there any other performance notes anyone can provide for a high speed usage efficiency? Anything would be appreciated!
Thank you.

I did a profile of a go app using goja, Following is a 30 second profile:

 flat  flat%   sum%        cum   cum%
 0.10s   0.3% 69.95%      0.47s  1.43%  github.com/dop251/goja.(*Runtime).typeInfo
 0.10s   0.3% 70.25%      4.59s 13.98%  github.com/dop251/goja.(*baseFuncObject).init
 0.10s   0.3% 70.55%     15.20s 46.29%  github.com/dop251/goja.(*vm).try
 0.09s  0.27% 71.13%     11.69s 35.60%  github.com/dop251/goja.getProp.exec
 0.08s  0.24% 72.44%      0.20s  0.61%  github.com/dop251/goja.cmp
 0.07s  0.21% 73.87%     15.40s 46.89%  github.com/dop251/goja.(*Runtime).RunProgram
 0.07s  0.21% 74.09%     11.48s 34.96%  github.com/dop251/goja.(*objectGoReflect)._get
 0.07s  0.21% 74.30%      0.49s  1.49%  github.com/dop251/goja.stringValueFromRaw
 0.07s  0.21% 74.51%      0.25s  0.76%  reflect.packEface
 0.06s  0.18% 74.70%      2.43s  7.40%  github.com/dop251/goja.(*Runtime).wrapReflectFunc.func1
 0.06s  0.18% 74.88%     11.59s 35.29%  github.com/dop251/goja.(*objectGoReflect).getStr

[PaluMacil]

I'm not sure what you're suggesting that might be actionable.

1. If you don't use maps, how do you expect to implement a dynamic language? Do you have any examples you think might be improved? If so, a PR with a benchmark followed by a PR with improved performance might be a good way to go about suggesting a change.
2. For structure depth, do you have any examples you think are incorrect or could at least be improved?

[neimanpinchas]

In regards to #1, I had a dream of an idea

Instead of using the standard go map, we could use a custom map based on custom efficient hashing with array as backend.
#1 based on the CPP book from BS it is always advisable to use arays over maps, for small quantities.
#2 we could prehash object keys that are in source code, in compile time, including object proto function access
#3 we could select a hashing alg optimied for small ASCII strings, such as 5 bit encoding in 64bit bit space, we coould add a flag in case we see that it doesn't fit and we want to use something else.

[timo-klarshift]

I am also using goja in a high performance environment and i came up with a solution which fits our needs.

Our requirement is that we have to run Java-Script scripts in a repeatable fashion with different contexts attached to it. We do this highly concurrently.

First of all you should wrap a single VM into a wrapper which would allow you to execute javascript throuh channels, this basically makes one engine thread safe.

The next step is to create a pool of engines, say 50 and you loadbalance requests over this pooled VM.

The final step is to pre-compile the scripts and cache them.

You should then also always use strict mode which prevents global pollution.

Here are some benchmarks of mine

func benchmarkRoutines(b *testing.B, engine Engine, maxCompilations int) {
	var wg sync.WaitGroup
	wg.Add(b.N)
	ctx := context.Background()

	for i := 0; i < b.N; i++ {
		go func(i int) {
			v, err := engine.Run(ctx, `return 1 + 2 + k`, map[string]any{"k": i})
			if err != nil {
				b.Error(err)
				return
			} else {
				assert.Equal(b, int64(3+i), v)
			}
			wg.Done()
		}(i)
	}

	wg.Wait()

	// There must be only a single compilation
	if maxCompilations > 0 {
		assert.Equal(b, uint64(maxCompilations), engine.ccount())
	}

}

cpu: Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz
BenchmarkDefaults-20                  	    8432	    129119 ns/op	  153554 B/op	    1939 allocs/op
BenchmarkCached-20                    	  239812	      5232 ns/op	    2593 B/op	      41 allocs/op
BenchmarkAsync-20                     	    8179	    147301 ns/op	  154061 B/op	    1942 allocs/op
BenchmarkAsyncCached-20               	  335208	      3963 ns/op	    3136 B/op	      44 allocs/op
BenchmarkAsyncPooled-20               	  304098	      4935 ns/op	    6473 B/op	      90 allocs/op
BenchmarkAsyncCachedAndPooled4-20     	  892962	      2316 ns/op	    2923 B/op	      44 allocs/op
BenchmarkAsyncCachedAndPooled16-20    	 1000000	      1751 ns/op	    2737 B/op	      43 allocs/op

[sohaha]

@timo-klarshift Can you share the specific benchmark code, I would like to refer to it.