JIT doesn’t seem like the big optimization that Rails needs. Rails has low throughput because you have to run multiple full-fat instances of rails to handle requests in parallel or multiple beefy threads to handle requests concurrently. Either way you’re spending a huge amount of ram to add a small amount of throughput.

JIT only adds a marginal improvement to this current setup.

A true async backend like Falcon adds a huge amount of concurrent throughput if tuned correctly and ractors could provide a big parallelism boost if they shared more memory.

I think in the context of high performance it is pointless to talk about Rails. Even the memory requirements make it impossible scale above a certain (very low) threshold.

In the context of developer productivity it is also pointless to talk about high performance because people sacrifice performance for developer happiness.

Once you understand that you have these two dimensions most frameworks are revolving around it is getting much clearer which one to pick for a certain use case.

This is legend. Rails can be and is used in high throughtput scenarios, people who say it can't scale all think they are working at Twitter while they just wrote inefficient code.

It is true that spending time optimizing queries will give you more benefits than JIT though. CPU is not the bottleneck for most Web tasks.

I think ORMs are part of the problem. By abstracting away SQL, it becomes really easy to write something that generates terribly inefficient SQL without realizing. It's easy to not realize it in small test environments with small test amounts of data, too.

Even a single n+1 query can really hose performance by burdening the entire database.

At least there are tools to warn you about n+1 automatically https://github.com/flyerhzm/bullet