「Rust每日新闻」调查问卷
还没有提交问卷的小伙伴,来填写一下问卷。
回头会把统计结果给大家分享,目前的统计结果很有意思,但是样本有点少,需要大家的配合。到时候把结果放出来,大家也可以对国内的Rust社区有一个了解。
「博文」一个使用Rust节约成本的故事
— 使用Rust将解析日志的速度提高了230倍
该文章是《The Ruby Way》的作者André Arko写的,同时他也是Ruby包管理器Bunlder的No.1贡献者,以及Rubygems.org的维护者。
所以,他在维护Rubygems.org的过程中,遇到最让他头疼的事情就是对日志的处理。Rubygems每秒有4000到25000个请求,磁盘每天可以产生500GiB的日志。他们尝试了一些日志的托管产品,但是这些产品也只能为他们保留1个小时以内的日志数据。
大概一年前,他把完整的日志进行了压缩,放到了s3上面,存储成本大概是每个月3.5美刀。但是有很多他感兴趣的统计数据被「埋葬」在了S3上面。因为S3的gzipped JSON流很难查询数据。这些统计数据有利于提供Ruby生态系统状态的重要信息。
后来利用aws的Glue功能,可以运行基于spark脚本的hadoop集群,他写了一个统计脚本,但是费用上升到了每月1000刀。
后来,也不知道是什么原因,让他想到了Rust。
事实证明,Rust满足了他的需求。 Serde Json库,让他可以在2秒内将1GB的JSON反序列化为Rust数据类型。并且使用nom来解析日志,可以在3分钟内解析1GB的日志文件,作者说,用Python和Glue在30分钟内解析完日志,他就觉得了不起了。
但是作者又仔细阅读了nom的文档,发现了一句「有时候,nom几乎和regex一样快」,这句话给了他灵感,他又用regex重写了解析代码,性能又提高了3倍。至少比spark中使用python解析快30倍。但是他把这个Rust程序的性能又多牛逼的事情告诉 @ReinH (他的朋友,Rust的贡献者之一,比他更了解Rust)的时候,ReinH说,怎么这么慢?你这个程序必须得优化。
他不清楚他的朋友是不是跟他开玩笑,但是他继续对Rust进行研究,然后他发现了—release
模式,在使用release模式编译代码之后,突然发现:他可以在8秒内把1GB的文件解析完。以下是处理速度的一个对比记录:
~525 records/second/cpu in Python on AWS Glue 50,534 records/second/cpu in Rust with nom 121,153 records/second/cpu in Rust with regex + release
但他没满足,继续使用rayon对程序并行化处理日志,最终的程序,在8核机器上快了100倍,在单核上跑,快230倍。现在的1GB的日志文件处理需要6.4s。
151,441 records/second/cpu in Rust with regex + release+ rayon
最后如何部署是个问题。
他尝试了一些方案之后,最后发现了aws Lambda,它有一个免费策略:每个月400,000s。而作者处理500GB日志,只需要3000多s。于是他就快乐地使用了aws Lambda功能。
源码 : kirby
「Rust前端框架」Draco:利用Rust和Wasm编写前端代码
灵感来自于React和Elm。使用了虚拟Dom。
一个在emacs中编辑rustdoc注释的好方法
Emacs 党可以看看
「小工具」字符串格式化库pfmt 发布0.4版本
Mondadic IO的Rust证明
「pre-RFC」域名作为命名空间
这是想Java化吗?(逃
「系列文章 Rust on Azure Functions Part 4」使用Rust和Wasm提升JavaScript 10倍速
更具体来说,该文涉及:
- wasm
- azure Functions
- 遗传算法
- 快速解决复杂的优化问题
前文「使用 rust+wasm提升Azure’s FaaS 性能的可能性」链接
「官方」举办了第一次编译器「 筹划指导委员会」会议
该会议主要是讨论接下来Rust编译器的发展方向,制定public roadmap、编译器文档、社区如何参与等问题。
每日新闻订阅地址:
欢迎通过GitHub issues投稿。
评论区
写评论哇塞,性能提高230倍……