Ruby YJIT 把 ActiveRecord 的速度提升了 1.37 倍
YJIT optimizes a number of common benchmarks well. Here are some results compared to the CRuby interpreter without MJIT, current as of Sept 2021:
activerecord: 1.37x
jekyll: 1.12x
liquid-render: 1.27x
mail gem: 1.09x
psych-load: 1.29x
Kokubun's railsbench: 1.16x
optcarrot: 1.68x
Chris Seaton's lee benchmark: 1.41x
Source code for these benchmarks can be found at https://github.com/Shopify/yjit-bench under "benchmarks".
貌似 Matz 同意合并了。
目前只支持 x86 平台，后续会支持 Arm 平台。对于不支持的指令或平台会回退到 CRuby
Github 和 Shopify 已经在生产上使用了，跑完测试后貌似并没有出现什么问题。
大家可以试用一下~
相关的资料： YJIT: Building a New JIT Compiler Inside CRuby YJIT: Building a New JIT Compiler Inside CRuby
pynix
回复
原来的 rails 团队就地解散。语言是码农的工具，码农是老板的工具，就象 obj/instance 是 class 的实例，class 是 Class 的实例一样
tablecell
回复
困扰到我的是内存 不仅仅是 ruby 内存 也不仅仅是 rails 内存 gem 内存 而是 内存
也许我的语文能力还没幼儿园毕业，让你理解起来费力了，我得好好反思下自己，多为社区添砖加瓦
jicheng1014
回复
如果 ruby 社区不用区分 ruby 内存/rails 内存/gem 内存 仅仅是内存困扰的的话，按 1 楼说的方案用 java 可是极好的，rails 团队原地解散，指望老板加内存来实现给 ruby 添砖加瓦根本不靠谱，老板都是用现成的，直接用现成的 java 的砖瓦，java 的砖瓦海了去了 相对 rails crud 甩 ruby 10 条街不止
tablecell
回复
说的没错 我是 10 年前就是写 java 的，现在 java 的 spring 生态也很好，绝大多数国内大公司最终业务都跑在 java 上
快速迭代速度和开发效率 ruby on rails 优势更大，ruby 社区的大多数人估计都赞成
我反思了下，确实你说的对，我没必要贬低其他人，要打拳我大可以去微博怼社会话题
最后祝我们为多为 ruby 社区添砖加瓦，做大做强
jicheng1014
回复
1 楼说的对，你也说得没错，我来总结一下，公司用 rails 的主要目的就是开头走个过场，rails 领进门，修行在 java，翻译成白话就是 传说中的导流量 导完流量后 原地解散的 Rails 团队再去 ruby 社区添砖加瓦，还能利用起来，最后把 ruby 社区做大做强 一点都不带浪费的。 做大做强 ruby 社区以后还可以打打拳去微博怼社会话题 顺便给微博导流量。多年以后，回顾 ruby 码农的一生，一生都在导流量 如果不是正在导流量，就在正走在去往导流量的路上
pv 在 1000w 以下的项目 rails 没什么大问题， 至于再大一些，我自己的项目没到那个量级，但是我觉得应该问题不大。
如果我创业，我肯定会选择 ruby 技术路线，虽然招一个 ruby 很贵（然而现在真也不贵，对比兄弟社区 testerhome 的测试招聘和社区最近的招聘），但是性价比很高，但凡搞 ruby 一阵子，基本都能做到能前端能后端能部署能运维，甚至有的能上到抗 ddos，下到 sketch 出图。两三个人就 run 个 A 轮的技术的 ruby 团队我都见过几个了。
Ruby 在国内确实存在最大的难题：ruby 圈人很少，之前在 2021 rubyconf 群里看见一堆老人，就感觉社区需要新人，需要新鲜血液
编个段子宣泄下情绪不是说不行，只是这么做意义不大，
困难大家都能看到，把问题解决了，才是正道
问题是不是就只能等大神的解决？
当然不是，是来自于社区的每一个人，
不是说 非得去 pr ruby, PR rails，提高运行速度 100%，才算解决问题
对社区的人友善，写一个新人友好的 教程，发一个用 ruby 开发的有趣指令，开源一个 rails 项目解决一个大家遇到的问题，或者自己创业时选择 ruby 作为主力语言， 都是对 ruby 社区的贡献。
还是那句话 大家多为社区添砖加瓦 做大做强
jicheng1014
回复
意义对每个人都是不同的，对码畜来说，让老板加内存条解决Rails 内存占用比较有意义，而对土憋老板来说 让码畜加班干活到11点而不付一分钱的加班费比较有意义 而 Linus 觉得写完代码炮轰 cpp 太烂有意义 统一的意义只有在西部世部的机器人写代码中才有。
有主张没办法是逃避问题，转移焦点的典型话术，这种情况一般是参加成功学培训多了，什么只要努力免费加班，就能加薪，只要努力挖煤，就能有一天当上煤老板。只要添转加瓦，Ruby 就有一天能做大做强之类的。
就我的个人观点，ruby 即没有必要做大做强 在可以预见的将来也不可能做大做强。 ruby 需要解决的是特定领域的特定问题，比如像金数据那样解决 form 表单的问题 象 sequel 那样初期解决项目原型快速迭代的问题
Rails3 在只专注后端，google 可以流畅访问的时侯，是可以实现项目原型快速迭代的，但是现在的 rails 版本捆绑着一堆强藕合东西，在众所周知的玻璃墙越架越高，各种花式限流的阻挠之下， 用 rails 实现快速迭代已经不再具有优势，反而低并发，高内存占用成为项目一定规模以后的棘手的难题。
现在技术领域有一个令人不安的趋势，资本提供一个主流解决方案 这个主流方案中的的出现的任何问题都应该回避，任何跟资本导向不利的方向都是被 diss 的，很象 weibo 上看不见，摸不着的各种红杠杠。你在够烂社区说最常用的 slice 都有很严重的坑，旁边马上跳出来一个码农说你态度有问题。 资本不仅控制着码农用什么技术 还在控制着码农用什么版本的技术 现在正在力图精细控制码农的面部表情，象西部世界那样让高级机器人写高级代码，生产另一批低级机器人写码畜们所写的那种 repeat 的代码正在一步步成为现实。 我说的不仅是 ruby 社区 而是所有技术社区都是这种趋势。资本控制下的码农不再去主导技术的发展，而是蜕化成一个跑龙套的，关心态度比关心技术问题本身更重要，更关心正能量，友善的态度，关心拉帮结派，拜山头，认大哥，交投名状 任何不随大流的都先揪出来批斗一番 至于讨论的技术问题是什么 根本不重要。 以前是在技术支持行业特别流行这个观念，你可以不解决客户面临的任何实际技术问题，但你一定要态度好，能讨客户欢心是最重要的，因为最终是客户掏钱买服务，客户花钱买个开心也是挺值的。 现在这个观念蔓延到了开发领域，技术本身不重要，需要解决的问题也不重要，重要的是要随大流，要有看齐意识，虽然大哥不发钱，但一定要紧跟大哥的步伐，要圈在笼子里千万不要到处乱跑，外面的世界太险恶了。
在形成资本控制的技术牢笼以后。老罗说的猴子不吃香焦的故事一遍一遍地重复上演 被圈在笼子里老猴子们已经习惯了不吃香焦 有新猴子胆敢吃香焦，老猴子们围上来不是解释1，2，3吃香蕉具体有那些坏处 而是上来就是一顿暴打。最大的梦想就是做大笼子，笼子要招新猴子，一定要招不吃香蕉的新猴子才可以
很不巧的的，我不是那种热衷听成功学讲座然后来回说车轱辘话回避实际问题的人 我是寻求解决方案的人 我最喜欢最热衷的事就是打破砂锅问到底，不见黄河不死心。回到主题 我想问的是
- rails 的高内存占用的终极解决方案是什么，是不是象码农那样一看 ide 内存不够了，按 reset 重启电脑就行了？
- rails 项目规模级超过 1000w 的后续解决方案是什么 是不是一劈两半，分裂两个 500w 的 rails 项目，让 rails 的天花板始终处于 1000w 以下
- 在人口结构421，玻璃墙越架越高的前提下，ruby 圈人很少 ruby 社区吸引新人的方案是什么，靠大哥说得对，你看我态度好浑身上下每个毛孔都散发着正能量 来吸引新人入圈吗？
jicheng1014
回复
还是要顺应大势，号召大家为社区添砖加瓦说实话没什么用，ruby 要再火除非出现一个像 rails 一样火爆的框架。创造和改变历史靠的往往是少量几个英雄人物，大部分普通人的作用只是喊 666。
tim_lang
回复
应该是有 gem 内存泄漏了。 除了选择 puma killer 还可以试试 systemd 本身有内存约束
我用 puma killer 有时候 worker 没起来
说 Rails 慢我也就勉强认了，说 Rails 吃内存的就有点过分了，2 核 4G 跑 4 个 Rails 服务，占用内存不过一半，JVM Spring 能比？gem 内存泄漏的问题，其实只要保证所有 gem 都是最新版就好了，历史上的泄漏都解了，社区都有一个网站专门说这个问题：https://www.rubymem.com
