byroot

26 ms·

241.
by byroot 4y ago
To be honest, Shopify isn’t particularly invested in Ruby concurrency. That’s not really a use case we have, and the community is already investing a lot in that direction (ioquatix with fiber scheduler and ko1 with N:M threads and Ractors)
242.
by byroot 4y ago
Hey Will, Pitchfork author here. As mentioned in the Readme, thanks for your Puma PR, it was indeed quite instrumental in Pitchfork inception. As for why it wasn’t used much as a Puma feature I don’t know, but there are a few challenges wit
243.
by byroot 4y ago
Why chose one over the other? Pitchfork’s selling point is that it allows you to reduce CPU usage with YJIT while still reducing memory usage compared to other servers.
244.
by byroot 4y ago
No, what is new here is reforking see https://github.com/Shopify/pitchfork/blob/master/docs/REFORK...
245.
by byroot 4y ago
Pitchfork author here. GVL contention is an issue when using threads of fibers, so it isn’t an issue with Unicorn
246.
by byroot 4y ago
Many parts of the stdlib are being slowly gemified, that's the case of `pstore` too hence why it has it's own repo. It's now no longer technically stdlib, but a "default gem", a gem that is installed by default with
247.
by byroot 4y ago
> distributing the work elsewhere, rather than getting concurrency right locally It's entirely orthogonal concerns. Job queues are for "fire and forget" tasks. Using Sidekiq and co offer tons of advantage over queuing this
248.
by byroot 4y ago
> My understanding was that you could ever only get green threads. Ruby 1.8 had green threads, 1.9 onwards has native threads, but with a GVL. And 3.2 may have N:M threads. > Is the GIL not going to be a thing any more? On paper it&#
249.
by byroot 4y ago
> that's still less elegant than simply performing those requests inline and not having to worry about all the additional moving parts that the jobs entail. I strongly disagree here. Going through a persisted queue gives you lot of
250.
by byroot 4y ago
> Usually that was in the form of long-running network calls. That's why doing a network call to another service in the middle of a request is pretty much banned from the monolith. Anything that doesn't have a strict SLO is don
251.
by byroot 4y ago
Yeah, that article is incorrect about the IO part, unless somehow they've been testing in development or something like that. It's however correct that partial rendering is quite more costly than it should, I explain why elsewhere
252.
by byroot 4y ago
> Each partial is an IO read No it's not. Once a partial has been compiled into bytecode, Rails doesn't reach to disk anymore, it's all in memory.
253.
by byroot 4y ago
> it's really depressing that nobody's been able to improve it. That's quite unfair, several people improved this already... > why partial lookup can't be cached at a given call site Well first you have no state at
254.
by byroot 4y ago
It is to some extent, the problem is in the semantic <%= render "foo" %> may end up rendering different partials based the context it's invoked from, e.g. current locale, etc. So the cache can't just be a simple ha
255.
by byroot 4y ago
> initial requires and configuration That happens at boot time, unless somehow you disabled eager loading or are not running in production mode.
256.
by byroot 4y ago
To be precise, it's not so much the partial rendering that's slow, but the partial lookup. When you do `<%= render "something" %>` Action View has to do a stupid amount of work to figure out which file it has to re
257.
by byroot 4y ago
Over half our reactors are currently stopped because of various corrosion issues, we regularly have to stop some because of drought, etc. France might have been the poster child for nuclear energy, but it’s on the verge of becoming a poster
258.
by byroot 4y ago
Even without an autoloader, Ruby has a single global namespace, so you have access to everything that has been required at any point from anywhere. If anything autoloaders enforce that constant names match filenames, making it easier to loc
259.
by byroot 4y ago
I don’t see why OP would need any of that to undo an history rewrite they messed up.
260.
by byroot 4y ago
Doesn’t git reflog answer that?
261.
by byroot 4y ago
CPU tasks (rendering views, instantiating objects, crunching numbers, etc) and GC.
262.
by byroot 4y ago
It very much isn't. Most well crafted Rails apps try to minimize IOs inside web requests by deferring any long IO into background job, and trying to optimize SQL queries. At best you may find apps that are 50% IOs. That may seems like
263.
by byroot 4y ago
Active Record async queries have nothing to do with fibers, the fiber scheduler or the `async` library. As for the heavy use of thread locals, we introduced an indirection to solve the problem. I can't say for sure every thing is irone
264.
by byroot 4y ago
It's in the works: https://bugs.ruby-lang.org/issues/18776
265.
by byroot 4y ago
That's what `ignored_columns` is for: https://api.rubyonrails.org/classes/ActiveRecord/ModelSchema...
266.
by byroot 4y ago
> yes shopify runs on truffleruby That's incorrect.
267.
by byroot 4y ago
It’s not that it’s highly coupled, just that it’s still the early days and only x86_64 was on the roadmap. Arm64 is planned, and will hopefully make it into Ruby 3.2
268.
by byroot 5y ago
It was explored but decided against, at least for now https://bugs.ruby-lang.org/issues/18653
269.
by byroot 5y ago
Not since about a decade. Plugins were Rails 1-2 era.
270.
by byroot 5y ago
This article is full of inaccuracies, I don't think the author really understand the subject. > As Rails continues to replace the usage of threads with fibers That's not what we're doing... Rails doesn't really use th

More ›