I already fixed it. Code in master branch. Will release soon. Please show full bench code.

You can find the complete test cases here: https://github.com/p1g3/golang-expression-evaluation-comparison

I see. Switch to this type for expr as well: func(args ...interface{}) interface{}

For celgo and govaluate you are using predefined type. In expr it called fast call.

I modified the code to:

params := map[string]interface{}{
		"hello": func(args ...interface{}) interface{} { return "hello " + args[0].(string) },
	}

However, the benchmark results show that this has not been very helpful.

cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Benchmark_bexpr-12 	 2863442	 2137 ns/op
Benchmark_celgo-12 	37168993	 162.3 ns/op
Benchmark_celgo_startswith-12 	21123087	 303.4 ns/op
Benchmark_celgo_funccall-12 	31582498	 174.8 ns/op
Benchmark_celgo_struct-12 	 7351293	 793.6 ns/op
Benchmark_evalfilter-12 	 3684661	 1610 ns/op
Benchmark_expr-12 	45209746	 133.1 ns/op
Benchmark_expr_startswith-12 	19628127	 275.4 ns/op
Benchmark_expr_funccall-12 	 7748418	 776.4 ns/op
Benchmark_expr_struct-12 	13065194	 450.5 ns/op
Benchmark_goja-12 	19866393	 303.6 ns/op
Benchmark_govaluate-12 	26049186	 229.4 ns/op
Benchmark_govaluate_funccall-12 	47708176	 128.9 ns/op
Benchmark_govaluate_struct-12 	 9306738	 680.0 ns/op
Benchmark_gval-12 	 9127659	 644.7 ns/op
Benchmark_otto-12 	 9173085	 643.4 ns/op
Benchmark_starlark-12 	 1322638	 4534 ns/op
PASS
ok 	github.com/antonmedv/golang-expression-evaluation-comparison	121.264s

I see. Switch to this type for expr as well: func(args ...interface{}) interface{}

For celgo and govaluate you are using predefined type. In expr it called fast call.

Is it true that while expr is much more concise and clear than go-cel and govaluate, the cost of doing so is sacrificing some performance?

Expr should be faster than cel-go and govaluate (definitely faster it). Let's try to figure our what the issue is: benchmark of expr call code.

So you think modifying the funccall benchmark to what would make it run faster?

I modified the code to:

params := map[string]interface{}{
		"hello": func(args ...interface{}) interface{} { return "hello " + args[0].(string) },
	}

However, the benchmark results show that this has not been very helpful.

cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Benchmark_bexpr-12 	 2863442	 2137 ns/op
Benchmark_celgo-12 	37168993	 162.3 ns/op
Benchmark_celgo_startswith-12 	21123087	 303.4 ns/op
Benchmark_celgo_funccall-12 	31582498	 174.8 ns/op
Benchmark_celgo_struct-12 	 7351293	 793.6 ns/op
Benchmark_evalfilter-12 	 3684661	 1610 ns/op
Benchmark_expr-12 	45209746	 133.1 ns/op
Benchmark_expr_startswith-12 	19628127	 275.4 ns/op
Benchmark_expr_funccall-12 	 7748418	 776.4 ns/op
Benchmark_expr_struct-12 	13065194	 450.5 ns/op
Benchmark_goja-12 	19866393	 303.6 ns/op
Benchmark_govaluate-12 	26049186	 229.4 ns/op
Benchmark_govaluate_funccall-12 	47708176	 128.9 ns/op
Benchmark_govaluate_struct-12 	 9306738	 680.0 ns/op
Benchmark_gval-12 	 9127659	 644.7 ns/op
Benchmark_otto-12 	 9173085	 643.4 ns/op
Benchmark_starlark-12 	 1322638	 4534 ns/op
PASS
ok 	github.com/antonmedv/golang-expression-evaluation-comparison	121.264s

The culprit with fastfunc although faster is fetchfn.. I just fetch the func directly from fetcher. fetchFN uses reflection and that is a killer.

call := vm.constant().(Call)
funcs := fetcher.Fetch(call.Name)

In my case I ensure all the fast funcs are not defined as methods.

Anton .. would love to see you re-instill fetcher as an option for those that can use it.

@gitperson1980 those bench are made at @master?

I did the benchmarks many moons back. I did it against v1.9.0. I still use v1.9.0 as it provides fetcher and fetcher is infinitely hackable to gain performance in my use cases. I love the fetcher functionality!

Also above 3 switch/case statements in fetcher.. Go compiler switches to binary search from a linear search.

Go compiler switches to binary search from a linear search.

Only for big switches.

What is the definition of big? Some of my fetchers have 50 case statements. It goes from O(n) to O(log n) with binary search.

I did some investigation. I added updated benchmarks in antonmedv/golang-expression-evaluation-comparison@6a03e5c

It is true, cel-go func calls now are faster. The reason for this is that Expr fetches function from the environment on the eval step, and cel-go does it on compile step. So Expr does an additional step, but this can be improved and Expr can also do such optimization on compile step.

Another huge difference is how functions are configured.

It's super easy to declare a function in Expr:

	params := map[string]interface{}{
		"join": func(a, b string) string {
			return a + b
		},
	}

And hot it's done in cel-go:

	env, err := cel.NewEnv(
		cel.Function("join",
			cel.Overload("join_string_string",
				[]*cel.Type{cel.StringType, cel.StringType},
				cel.StringType,
				cel.BinaryBinding(func(lhs, rhs ref.Val) ref.Val {
					return types.String(lhs.Value().(string) + rhs.Value().(string))
				}))))