4 ms·
I'm all for questioning the validity of certain code patterns, but there's some issues with this post. Functional Options (or config/option initialization) sho
by eudoxus 4y ago
I'm all for questioning the validity of certain code patterns, but there's some issues with this post.
Functional Options (or config/option initialization) shouldn't really ever happen in a "hot path" where performance really matters, as these are usually one off steps at the time of construction/initialization. As with most things in Go, start with usability/readability then measure and tune when/where needed.
With that in mind, the author doesn't give a concrete example of when a Functional Option pattern might be used in a hot path, in which case, certainly agree there are better patterns to use.
Then adds the benchmarks which (ignoring function inlining) are relatively comparable for Functional Options vs Config Struct, with the notable increase when using interfaces (as with many things in Go). But these results are still on the order of ~100ns. I think more accurately they can be characterized as "Relatively" slow.
- infogulch 4y agoThis is the proper frame to analyze this issue. If you're using Functional Options to configure a long-running http server once at startup, the cost is so small that you've already spent more money thinking about it for 1 minute than it will ever cost in compute runtime. But if you're using it once per request over thousands of requests, or once per record with thousands of records per request then maybe it's time to consider using a more lightweight configuration pattern.
- jeffbee 4y agoThe functional pattern on every request is quite common. Think gRPC-go's withContext(withDeadline()) pattern.
- wbl 4y agoIf you are trying to shave nanoseconds off an RPC you have architectural issues.
- jeffbee 4y agoIf you approach every program with that attitude you will never have an RPC subsystem where nanoseconds matter. You will be trapped in a self-fulfilling process where nanoseconds don't matter because the system is slow.
- lmm 4y agoIt's physically impossible for nanoseconds to matter for remote calls - most individual servers are larger than one light-nanosecond.
- jeffbee 4y agoThe efficiency of initiating the call limits how many calls the program can initiate per second, per thread. The potential latency of the response is irrelevant.
- chimeracoder 4y ago> Functional Options (or config/option initialization) shouldn't really ever happen in a "hot path" where performance really matters, as these are usually one off steps at the time of construction/initialization. That's not true at all. As just one counterexample, the place where I have spent the most time wrestling with functional options is with OpenTracing, where performance overhead absolutely does matter.
- onionisafruit 4y agoThey said “shouldn’t” not “doesn’t”. A good rule of thumb is don’t use open tracing in any functions where you expect to measure anything less than 10ms.
- eudoxus 4y agoExactly, general rule of thumb: One shouldn't deal in absolutes ;).