Skip to content

Why the best way to define a function from a performance perspective is to use the expr.Function option. #734

Closed

Description

@HoChihchou

The best way to define a function from a performance perspective is to use a Function option.

Quoted from documentation(https://expr-lang.org/docs/functions)

This is my benchmark test:

package main

import (
	"strconv"
	"testing"

	"github.com/expr-lang/expr"
)

type EnvStruct struct{}

func (EnvStruct) Atoi(input string) int {
	value, _ := strconv.Atoi(input)
	return value
}

func BenchmarkCustomFunctions(b *testing.B) {
	exprString := `Atoi("42")`

	// Method 1: Add to environment
	envMap := map[string]interface{}{
		"Atoi": func(input string) int {
			value, _ := strconv.Atoi(input)
			return value
		},
	}

	compiledEnvMap, err := expr.Compile(exprString, expr.Env(envMap))
	if err != nil {
		b.Fatal(err)
	}

	// Method 2: Define on struct
	envStruct := EnvStruct{}
	compiledEnvStruct, err := expr.Compile(exprString, expr.Env(envStruct))
	if err != nil {
		b.Fatal(err)
	}

	// Method 3: Using Function option
	atoiFunc := expr.Function(
		"Atoi",
		func(params ...interface{}) (interface{}, error) {
			return strconv.Atoi(params[0].(string))
		},
		strconv.Atoi,
	)
	compiledFunc, err := expr.Compile(exprString, atoiFunc)
	if err != nil {
		b.Fatal(err)
	}

	b.Run("EnvMap", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			r, _ := expr.Run(compiledEnvMap, envMap)
			if r != 42 {
				b.Errorf("got %v, want 42", r)
			}
		}
	})

	b.Run("EnvStruct", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			r, _ := expr.Run(compiledEnvStruct, envStruct)
			if r != 42 {
				b.Errorf("got %v, want 42", r)
			}
		}
	})

	b.Run("FunctionOption", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			r, _ := expr.Run(compiledFunc, nil)
			if r != 42 {
				b.Errorf("got %v, want 42", r)
			}
		}
	})
}

And result

goos: darwin
goarch: arm64
cpu: Apple M1 Pro
BenchmarkCustomFunctions/EnvMap-10              24067287                48.26 ns/op
BenchmarkCustomFunctions/EnvStruct-10            3250443               365.2 ns/op
BenchmarkCustomFunctions/FunctionOption-10      19875295                60.49 ns/op
PASS
ok      command-line-arguments  4.534s
goos: darwin
goarch: arm64
cpu: Apple M1 Pro
BenchmarkCustomFunctions/EnvMap-10              23904123                48.59 ns/op
BenchmarkCustomFunctions/EnvStruct-10            3274218               374.6 ns/op
BenchmarkCustomFunctions/FunctionOption-10      19192731                61.28 ns/op
PASS
ok      command-line-arguments  4.460s

The performance of map and function methods are very close, there is no particularly obvious difference, and map method is even faster.

Activity

  1. mdmcconnell commented on Nov 27, 2024

    @mdmcconnell
    Contributor

    This is great, very helpful! I've wondered about this since I make heavy use of functions. It's nice to have data.

  2. antonmedv commented on Nov 27, 2024

    @antonmedv
    Member

    Nice benchmark!

    I put a lot of effort to make function calls as fast as possible.

    This is still true: The best way to define a function from a performance perspective is to use a Function option.

    In your case the map slightly outperforms Function due to a heavy ammount of optimizations. But for general, uncommon func signature results will be different. True for example: func(int, string, int, time.Time, uin16) or any other random funcs signatures.

  3. HoChihchou commented on Nov 27, 2024

    @HoChihchou
    Author

    For such a function func(int, string, int, time.Time, uin16) , will the expr.Function be much faster than the map? Or is it just a little faster?

  4. antonmedv commented on Nov 27, 2024

    @antonmedv
    Member

    Faster. But on how much - benchmarks are needed.

  5. locked and limited conversation to collaborators on Mar 10, 2025
  6. converted this issue into a discussion #767 on Mar 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions