Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
byroot
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
151.
▲
by
byroot
3y ago
"speed" thrown without context is meaningless. It's one property of a tool among many others you generally have to trade for. Some use cases with small margins call for the utmost efficiency to be viable business. Some use ca
152.
▲
by
byroot
3y ago
In the yjit-bench suite, there are a number of micro benchmarks that had a 2-3x gain between 3.2 and 3.3: https://speed.yjit.org/stats-timeline.html But my point is that the YJIT team never really communicate numbers from s
153.
▲
by
byroot
3y ago
This number is from a production workload with a significant chunk of IOs. If you look at CPU bound micro-benchmarks like most similar announcements uses, you easily get into the 3x territory: https://railsatscale.com/2023-1
154.
▲
by
byroot
3y ago
Can we stop with these useless comparisons? 10x-20x, 100x, 200x out of context means absolutely nothing. All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not
155.
▲
by
byroot
3y ago
There is a few alternatives like getaddrinfo_a(3) but they have other downsides (fork safety concerns). If you want more context, you can read: https://bugs.ruby-lang.org/issues/19430
156.
▲
by
byroot
3y ago
I don't see how it's relevant given that YJIT didn't cause any compatibility issue whatsoever.
157.
▲
by
byroot
3y ago
A fiber doesn't have a dedicated execution context, so it would be just as blocking.
158.
▲
by
byroot
3y ago
Mike Perham (the sidekiq maintainer) also maintains the less well known faktory[0] which is language agnostic and has runners for both Ruby and Python [0] https://github.com/contribsys/faktory
159.
▲
by
byroot
3y ago
It's a Ruby thing. Ruby only has a single global namespace, no imports. If anything Rails autoloading (Zeitwerk really) make it much easier to find where constants come from as it enforce a constant name -> file name convention, so
160.
▲
by
byroot
3y ago
To be slightly more correct, there is inlining but only of trivial methods that simply return an immediate value or a constant, e.g. class NilClass def blank? true end def present? false end
161.
▲
by
byroot
3y ago
Weird, because if anything I keep hearing people say Ruby performance and GVL don't matter because it's all IO anyway. Which is true to a certain extent only. When you first start optimizing a Rails app, it's true that bad qu
162.
▲
by
byroot
3y ago
On what, mmTk? Matt's talk at latest Ruby Kaigi is a good intro: https://www.youtube.com/watch?v=chhNDhyPbyc
163.
▲
by
byroot
3y ago
> but AFAIK there’s no one on core who wants to own it right now. Active Record is probably the "most owned" part of Rails, that's the one with the most core members and committers with deep knowledge of it. As for your fe
164.
▲
by
byroot
3y ago
YJIT won't help JSON generation because it's all implemented in C (either the stdlib `json`, or `oj` or `yajl` etc. If what is slow is some RUby code like Active Model Serializers etc, then maybe it can help a bit there. But yes,
165.
▲
by
byroot
3y ago
There is still lots of optimizations to make. On the JIT side, there is still no inlining, which opens the door to much more aggressive optimizations. But also on memory as well. There was a lot of improvements done on the Ruby garbage coll
166.
▲
by
byroot
3y ago
> Protected methods can be invoked on self or with an implicit receiver. No, protected method can be called on self or from other instances of the same class. Typically used for implementing `==` methods. > Private methods can only be
167.
▲
by
byroot
3y ago
> Would you then agree that an event loop is very well suited for web server workloads, with short lived requests + reasonably light CPU usage + lots of IO, which happens to be the territory both Rage and Puma are situated? No, that'
168.
▲
by
byroot
3y ago
My point is that event loop are not inherently superior to thread pools. When you have a workload that is CPU heavy enough that you won't have more than a handful of threads of concurrency, using a thread pool will allow preemption, he
169.
▲
by
byroot
3y ago
> So what would be a better benchmark? It all depends on what you are trying to demonstrate. The current benchmarks would be fine if properly contextualized and presented a bit differently. e.g. for the first one, instead of representing
170.
▲
by
byroot
3y ago
That is precisely my point. One has concurrency capped at 5, the other has no cap (because it uses an event loop). The Puma process is likely 99% idle in that benchmark, you could crank up the thread count to 50 and get (not quite) 10x bett
171.
▲
by
byroot
3y ago
Because unless you want to expose your Ruby server directly to the internet without a load balancer, there isn't much to gain in having HTTP/2 between the LB and the app server. I'm curious though, what's your use case t
172.
▲
by
byroot
3y ago
Lies, damn lies and benchmarks. The first benchmark is pretty much an empty request, so it measure each framework "overhead". That shows Rails+Puma at `0.25ms` overhead per request, and rage+iodine at `0.013ms`. That is significan
173.
▲
by
byroot
3y ago
> The JVM team looks closer to the YJIT project. That's the same team (Rails + Ruby)... > Making a JIT also calls into question Shopify's scalability: Rails was slow enough that they allowed a JIT to be built internally? You
174.
▲
by
byroot
3y ago
That's absolutely not a huge overhead, quite the contrary it has many benefits. We do the same at Shopify, and running off the edge allow to catch bug much sooner and identify them much easier. It also very significantly cuts down on m
175.
▲
by
byroot
3y ago
As @xerxes901 said, there's some major challenge in freeing just one method code as it's not necessarily contiguous, and also it's of very variable size so it would generate lots of fragmentation. The allocate would need to b
176.
▲
by
byroot
3y ago
You can attach to a running Ruby process with rbtrace easily.
177.
▲
by
byroot
3y ago
The limiting factor isn't the size of the dataset, but the rate of writes.
178.
▲
by
byroot
3y ago
You are quoting out of context, losing the meaning of the quotes. The conclusion of Eileen's talk is that by not following with upgrade and essentially forking Rails 2.3 they painted themselves in a corner. They took short term gains,
179.
▲
by
byroot
3y ago
I'm a Rails core member too, and Eileen is my colleague... You are interpreting both links you gave in terrible ways.
180.
▲
by
byroot
3y ago
> It will plataue Yes, because extra empty pages are released at the end of major GC, which is occasional, and most web application will cyclicaly use enough memory that they will stabilize / plateau at one point. > I believe tha
More ›