Consider using RCPP_USE_UNWIND_PROTECT for improved performance
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 领域
- backend, performance
调研方向
Start by inspecting the package build configuration and how Rcpp::Function calls are used in the server callback path. Compare the existing dplyr Makevars use of RCPP_USE_UNWIND_PROTECT, then run the documented wrk hello-world benchmark with and without the flag; done means a justified default build choice with no regressions in request handling.
由索引模型根据 Issue 内容生成。
描述
I was doing some casual profiling of some httpuv servers and noticed that the call stack was deeper than I expected. You can see in the flame graph below (for the "hello, world" example) that there is a tryCatch/eval stack between later::execCallbacks() and the actual call() method (anonymous here) for the server:
I eventually worked out that this tryCatch/eval setup is manually created in C++ code when evaluating an Rcpp::Function, in order to prevent longjmps. This might be well-known. However, it is also apparent from the flame graph that this particular stack seems to impose a significant amount of overhead on all requests, and I wondered if removing it could improve performance.
As it turns out, Rcpp has a not-very-well-advertised configuration option to avoid this in favour of newer C-level features of R, RCPP_USE_UNWIND_PROTECT (originally implemented by Lionel Henry, I believe). This flag is used by some existing packages, dplyr among them, so it probably has few downsides.
To illustrate the potential difference, I ran some load testing for the "hello, world" server against vanilla master:
$ wrk -d 20 -c 10 -t 2 "http://127.0.0.1:5000/"
Running 20s test @ http://127.0.0.1:5000/
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 2.55ms 1.57ms 41.95ms 96.25%
Req/Sec 2.03k 139.92 2.39k 75.25%
80786 requests in 20.01s, 7.70MB read
Requests/sec: 4038.18
Transfer/sec: 394.35KB
And with PKG_CPPFLAGS += -DRCPP_USE_UNWIND_PROTECT:
$ wrk -d 20 -c 10 -t 2 "http://127.0.0.1:5000/"
Running 20s test @ http://127.0.0.1:5000/
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.76ms 1.36ms 39.96ms 97.78%
Req/Sec 2.98k 288.29 6.39k 77.56%
118950 requests in 20.10s, 11.34MB read
Requests/sec: 5917.94
Transfer/sec: 577.92KB
As you can see, throughput is about 50% higher. The accompanying flame graph, showing the simplified stack, is below:
In light of this, I believe that you should consider building httpuv with RCPP_USE_UNWIND_PROTECT by default, if possible.
- 主要语言
- C
- 星标
- 252
- 派生
- 87
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
rstudio/httpuv 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 64/100
-
难度 4/5 3-5 天 新手友好度 46/100
-
难度 5/5 一周以上 新手友好度 30/100
-
难度 4/5 3-5 天 新手友好度 45/100
-
难度 4/5 3-5 天 新手友好度 35/100
相似的 Issue
-
Status: Opened
难度 2/5 1-3 小时 新手友好度 64/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
FriendsofECCE/ECCE#1018 ·
-
难度 2/5 1-3 小时 新手友好度 62/100
immortalwrt/immortalwrt#2522 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
severity: low
难度 2/5 1-3 小时 新手友好度 64/100
luainkernel/lunatik#2530 ·
维护者通常 1 天内回复