@RTSmile 毕竟是 std 的问题, 修复蛮麻烦的.

benchmark 一下就能看出来, 我原来还不信的.

最简单的复现代码, 虽然不够严谨. 严谨点得用 benchmark, 或者上火焰图看看什么情况, 我对为什么慢不感兴趣所以没弄.

```rust
fn main() {
let mut result = Vec::with_capacity(20);

for _ in 0..20 {
let now = Instant::now();

for _ in 0..10000 {
let _ = anyhow::anyhow!("test error");
}

result.push(now.elapsed().as_nanos());
}

let avg = result.iter().sum::<u128>() as f64 / 20f64 / 1000f64;

println!("avg cost: {}s", avg);
}
```

反正我现在是遵照一位大佬的建议锁 1.0.76 这最后一个正常的版本, 然后所有依赖 anyhow 的库也基本会对齐依赖版本. 还在观察中, 后天有空看看 nightly 版本下的情况.

对于此问题, 修复方法推荐强制指定 anyhow 版本到 =1.0.76

测试环境:
rustc 1.78.0 (9b00956e5 2024-04-29), PTLin 给出的代码

Linux 平台仍然观察到了明显性能折损, profile.release 下, 使用 =1.0.86 版本的 anyhow 比 =1.0.76 版本的 anyhow 慢了 2 倍有余(default-feature = true 下)... 相当恐怖...

btw, 个人有个 gRPC server 的项目, 观察到 prost 间接依赖了 anyhow, 只能说但凡涉及 gRPC 的几乎全都会受影响, 毕竟 prost 的影响力蛮大的...

bbtw, 得 anyhow = { version = "=1.0.70" } 这样才能强制指定版本.

29 的 2020 芝麻卡套餐其实还行, 5~7GB 可结转通用和 30GB 定向, 如果平时大流量需求在定向范围这个很合适, 就是不知道现在能不能办(应该不可以了除非投诉), 或者有没有类似物.

@securityCoding 毕竟写 c++ 的心智耗费蛮大的, 特别是所谓 modern c++.

贴个偶然间看到的 issuecomment 片段, 阐述了为什么 SRS 坚持使用 c++98, ref: https://github.com/ossrs/srs/issues/1191#issuecomment-917324341

```
No, I still firmly believe that if we can use C++98, we should definitely not use C++11. The more complex language features we use, the smaller the target audience of developers becomes. Even the senior brother finds C++98 too complicated, let alone C++11. I hope all C programmers can easily modify the code of SRS.
```

现在相当一部分客户端都内置 http dns 或其类似物了吧, 付费上阿里云等厂商的方案, 或者白嫖用 DoH 的方案.

Ref: https://www.aliyun.com/product/httpdns, https://cloud.tencent.com/product/httpdns

所以实在受不了 Canonical 的骚操作就投入 Debian 的怀抱吧.jpg, 特别是生产环境给服务器用的, Debian 干净多了, 要高级支持不如 RedHat 系列.

虽然日用 Debian 就一毛坯房, 啥都得得自己装修, 最近从 Windows 切换过来还蛮不习惯的.

差点看不懂标题(笑), 但是这玩意我感觉也没那么好用啊, 这回加速脱坑了

@xuwuyibing 好家伙, 顺带直接变成国际版 Bing, 没有搜索限制, 用的还是国内的 CDN, 真不错()

@idolphin 这是浏览器限制的, 最好还是下到本地看

自建音乐库+MusicBrainzPicard 完善 meta 信息, 应该也差不多, 500G 音乐这辈子也听不了() 音源多数从论坛扒, 部分是开个月费会员下个够

@maichaide 求问 OP 同步进度

我这有公网 ipv6, 除了 80 和 443 其他端口随便连没限制. 在用的套餐是 270 多一年 1000M 下行+50M 上行, 不过是每年限定的活动, 每年活动不一样, 得联系宽带师傅. 常规价格是 30 元一个月 300M+30M(首年免费, 应该是有 29 元以上的套餐限制), 20 元一个月 100M+10M(没有低消, 8 元套餐也可以, 用 29 以上的首年免费). 可能是穷地方推广吧才有这优惠. 想有优惠最好找点在移动工作的熟人问问.
以上套餐均有公网 ipv6, 除了 80 和 443 其他端口随便连没限制. 光猫也不用改桥接, 把线插路由器的 LAN 口就行, 手机 wifi 都可以拿到 ipv6 地址, 拿来 zerotier 打洞访问家里的 nas 爽歪歪

@AyaseEri 现在还疯狂压码率, 非大会员的画质跟狗屎一样, 1080P 码率基本是 1080P 码率砍半甚至更多, 直播也强制二压降码率

@Zyilin98 上面也说到, 走 ipv6 大概率拿到传统 CDN, 可能这是破局之路了, 只不过蛋疼的是校园网的 wifi 电脑能拿到 ipv6 地址但手机拿不到

前几天甚至网页端 console 直接显示 vue 的测试信息()

@viosey 好像也不太一定, 可能还考虑了服务器压力, 低峰期正常的 CDN 就比较多. 目前好像这个 CDN 地址是保存在 HTML 里面的, 直接访问网页拿到的 CDN 地址就全是 MCDN(百大 UP 主的就比较少). 而且非常有趣的是, 直接 curlB 站获取视频地址的 API, 拿到的视频地址鲜少 MCDN, 更不用说 PCDN 的了.

@mztwfed 校园网只有 ipv4 就慢的一批, 总是分配 mcdn(帝都没有 pcdn 好像, 老家就很多 pcdn)而且速度奇慢. 换 5G 后就分配 Mirror 型比较多了, 走 ipv6. 所以我认为你的测试结果是比较可靠的. 实测网页端屏蔽 PCDN 会导致加载不出来, 前端请求视频地址的时候应该会判断客户端类型, PC 端分配的就大多数是 MCDN 或者 PCDN, 手机客户端还好. 请求视频地址会返回 4 个可用地址, 里面一般会分配两三个 PCDN 型和一个 Mirror 型或 MCDN 型, 我想能不能写个插件提取里面的 Mirror 型地址, 或者拿云函数自建一个地址代替官方 api 确保分配到 Mirror 型地址. 应该视频在 Mirror 型的服务器都是有的, 没有就多试几个, 只不过为了省流量就分配优先级不高而已