Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's discuss performance #19

Closed
christian-blades-cb opened this issue Jan 11, 2017 · 6 comments
Closed

Let's discuss performance #19

christian-blades-cb opened this issue Jan 11, 2017 · 6 comments

Comments

@christian-blades-cb
Copy link

I was curious what the performance impact is of your functional implementation vs the classic implementations. I haven't gone in depth, but the results are interesting (in particular the memory allocations for Contains.)

➜  funk-bench git:(master) ✗ go test -benchmem -bench .
testing: warning: no tests to run
BenchmarkContains/Idiomatic-8               1000           1946239 ns/op               0 B/op          0 allocs/op
BenchmarkContains/funk-8                       2         645429814 ns/op        28916552 B/op    3614564 allocs/op
PASS
ok      github.com/christian-blades-cb/funk-bench       4.417s
@thoas
Copy link
Owner

thoas commented Jan 11, 2017

Hay :)

I haven't done the benchmark yet, but it doesn't surprise me since the reflect API relies on allocations, however it's in my TODO

@thoas thoas changed the title Discussion: benchmarks Performance Jan 12, 2017
@thoas thoas changed the title Performance Let's discuss performance Jan 12, 2017
@thoas
Copy link
Owner

thoas commented Jan 12, 2017

I have added a performance section in the README, you are totally right on this point we must bring this subject on the table and also provide typesafe solutions (less flexible).

@thoas
Copy link
Owner

thoas commented Jan 12, 2017

Typesafe implementations are on the way, I will add more benchmarks bit by bit.

@christian-blades-cb
Copy link
Author

Wow! You've been busy! Excellent work.

I'd love to explore why using reflection has so many more allocations, 10 minutes on google wasn't enlightening. Would make a good article.

@marklr
Copy link

marklr commented Jan 16, 2017

@christian-blades-cb, would doing some memory profiling with the -runtime flag shed some light on the allocation churn?

@taowen
Copy link

taowen commented Jan 20, 2017

@thoas I have implemented a way to avoid the cost of reflect.Value

https://github.com/json-iterator/go/blob/master/feature_reflect.go

The general idea only rely on reflect.Type to assemble your function logic through composition. Then working with raw unsafe.Pointer directly. Essentially, interface{} is a reflect.Type + raw pointer.

@thoas thoas closed this as completed Jun 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants