3 ms·
This 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
by infogulch 4y ago
This 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.