TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How to Fix Slow Code in Ruby

210 点作者 gmcabrita大约 5 年前

13 条评论

benkuhn大约 5 年前
Really surprised how many commenters are talking about using a faster language when the example of slow code <i>in the post</i> is failing to cache the results of an expensive database query.<p>In my experience, even in &quot;slow&quot; languages, that type of thing is the predominant source of major performance problems, and the supposedly &quot;slow&quot; language would be perfectly adequate if you an stop shooting yourself in the foot (and if you can&#x27;t, a faster language will not help you).<p>I&#x27;m sure there are extremely high-performance or high-scale points where language choice starts to matter more, but I&#x27;m also not surprised if Shopify is correct not to think they&#x27;re there yet.
评论 #23187579 未加载
评论 #23187513 未加载
评论 #23190166 未加载
rdoherty大约 5 年前
First thing I tell anyone when they say &quot;this code is slow because of X&quot; is to profile it. Profile, profile, profile! More often than not your assumptions are wrong.<p>There&#x27;s a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There&#x27;s definitely a jump between making guesses and hoping you improve performance vs truly understanding what your code is doing.
评论 #23190898 未加载
alberth大约 5 年前
What&#x27;s current state on GraalVM as it relates to running production Ruby code?<p>From what I understand, it&#x27;s the fastest VM out there at the moment for Ruby.<p>And yes, it&#x27;s from Oracle but they have GPL&#x27;d the code [2]<p>[1] <a href="https:&#x2F;&#x2F;www.graalvm.org" rel="nofollow">https:&#x2F;&#x2F;www.graalvm.org</a><p>[2] <a href="https:&#x2F;&#x2F;www.graalvm.org&#x2F;docs&#x2F;faq&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.graalvm.org&#x2F;docs&#x2F;faq&#x2F;</a><p>Edit: looks like TruffleRuby is built onto of Graal.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;oracle&#x2F;truffleruby" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oracle&#x2F;truffleruby</a>
评论 #23186510 未加载
评论 #23183893 未加载
评论 #23185920 未加载
评论 #23184750 未加载
llamataboot大约 5 年前
I even have a little method in my .pryrc that lets me easily benchmark on the fly in the console<p>def benchmark_time(repetitions = 100, &amp;block) require &#x27;benchmark&#x27; Benchmark.bm{ |b| b.report{ repetitions.times(&amp;block) } } end
praveenperera大约 5 年前
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing&#x2F;rewriting new&#x2F;critical paths of the codebase in a faster language.<p>Ruby used to be able to say we sacrifice performance for developer productivity.<p>I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing wildly more performant code.
评论 #23186777 未加载
评论 #23186665 未加载
评论 #23186614 未加载
评论 #23186861 未加载
评论 #23186453 未加载
评论 #23187001 未加载
stevebmark大约 5 年前
Benchmarks are subjective, but <i>all</i> benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower.<p>It fundamentally <i>has</i> to be slower. Ruby is the most dynamic of the dynamic programming languages. And the community has embraced metaprogramming, making it every more dynamic. Especially on webservers, you&#x27;ll be executing hundreds, sometimes thousands, more lines of code than other servers, especially in a mature system.<p>Is it &quot;slow&quot; enough to matter? Probably not until you get to a medium scale. Everywhere I&#x27;ve worked, we&#x27;ve had to on average double the hardware specs for Ruby servers to make them as performant as other dynamic language applications we run. Not the most expensive thing in the grand scheme of things, but there are entire cottage industries of magically tuning Ruby and Rails that you don&#x27;t have to worry about with other systems until much larger scales.
评论 #23183091 未加载
评论 #23183039 未加载
评论 #23183379 未加载
评论 #23183641 未加载
评论 #23183007 未加载
评论 #23187063 未加载
评论 #23184865 未加载
jbverschoor大约 5 年前
Tuby is almost the only language which has a really really good, clear and well thoughout standard library.
评论 #23189561 未加载
lidHanteyk大约 5 年前
Interesting; Shopify doesn&#x27;t use TruffleRuby, but instead prefers MRI?
评论 #23182907 未加载
评论 #23182765 未加载
评论 #23182920 未加载
The_rationalist大约 5 年前
Any performance benchmarck of jruby vs truffleruby vs ruby?
评论 #23183341 未加载
fxtentacle大约 5 年前
C++<p>It&#x27;s that easy :)
评论 #23184820 未加载
评论 #23184589 未加载
StreamBright大约 5 年前
Seriously, if you need high performance out of the box, you should probably just skip Ruby. I love that language to death but most of the time you cannot use of it for a decent scale.
评论 #23185245 未加载
timwis大约 5 年前
There’s a much easier way: just increase `Rails.application.speed` from 5 to 10 in the application config.
pdimitar大约 5 年前
...Rewrite in almost anything else and you&#x27;ll have fast code. :)<p>It&#x27;s quite amazing the lengths the companies will go to just to avoid changing their status quo. But for them it makes sense.<p>---<p>EDIT: Downvoters, calm down. Ruby on Rails is objectively quite a slow framework and this is proven in many public benchmarks (Techempower included). And Ruby isn&#x27;t the fastest among the dynamic languages either.<p>Less cargo culting and more facts, please.
评论 #23186134 未加载