3 ms·

That is kind of irrelevant if you are running a Ruby application. And I think that if a developer is looking to start working on a new web server where performa

That is kind of irrelevant if you are running a Ruby application. And I think that if a developer is looking to start working on a new web server where performance is a significant concern, they are more likely to look at Go, Rust, or even JavaScript rather than either Lua or Ruby.

CyberDildonics 4y ago
LuaJIT should be much faster than javascript Also how slow is still ok? People can talk about things that aren't 'performance sensitive' but at some point it's going to matter. If a program is serving up web pages, that's an interactive application and people are waiting on the program.
- winrid 4y ago
  Even a slow framework is still fast for humans. My Django site renders the homepage in 10ms, and django is kind of in the realm of Rails performance wise. It's all about cost, really. But you can just tell Nginx to cache pages and then it's not a problem for the vast majority of use cases.
  - ksec 4y ago
    Oh well if all the Rails site could render a medium size App with 10-20ms response time then no one should be complaining.
    - winrid 4y ago
      Well if you start fetching thousands of objects without projections and maybe make a couple writes per page load then yeah, it's gonna be slow.
- brokencode 4y ago
  JavaScript is so much more widely used for so many applications that it’s hard to justify LuaJIT, even if it is faster. They’re both much faster than most scripting languages like Python and Ruby. If JavaScript really isn’t fast enough, then I think you should be thinking about something like Go or Rust instead. LuaJIT is an incredible piece of technology, but in this performance tier JavaScript has won out due to sheer ubiquity and the size of its ecosystem. Edit: I never said slow was okay. I’m not advocating for slow, I’m just saying that the target audience for RJIT is developers who are already using Ruby. For significantly better speed, you probably want to look elsewhere.
- JohnBooty 4y ago
  Also how slow is still ok? People can talk about things that aren't 'performance sensitive' but at some point it's going to matter Done a fair amount of Rails perf tuning over the years. One of my favorite things to work on. "Fast enough" for me, is when your web framework is nowhere near your bottleneck. On your average web app endpoint you're probably spending 95-99% of your time on external calls to Redis/Postgres/etc and Postgres is probably your specific bottleneck. For these apps, Rails is most definitely fast enough. You could rewrite your app layer in well-tuned C or assembly and guess what, it's getting maybe 1-5% faster if you're lucky. Maybe you get from 100ms down to 95ms and all you had to do was rewrite 100,000 lines of Ruby in 200,000 lines of C. For other cases, obviously, maybe Rails is your bottleneck. Maybe you're providing a read-only API and everything is cachable in RAM. Rails will be fast, maybe 10ms per request, but a faster framework can spew out responses in 2ms and now you have 5x the capacity and your P95s during peak hours are really smoothed out.
  - ksec 4y ago
    For Rails as an API? Yes. There are plenty of examples where Rails as an API, and specifically not using ActiveRecord, gets you 10ms response time excluding DB. But most of the Rails app, especially those with ActiveRecord and Server side rendering spend 60+% of response time, And in many cases even higher before hitting DB. And they fall into 100 to 200ms response time category.
ecshafer 4y ago
Performance is a weird metric for a web application. You can say Go or Rust will be more performant than Ruby or Lua, sure. But with web applications so often your performance has nothing to do with the language or hiccup. But you aren't just processing N requests and spitting out a response, you are communicating with other services and databases. IO is almost always a bigger source of latency in response than language speed, until you have a large enough service where you can start to worry about those small issues. Before the Developer performance matters more.
- wiseowise 4y ago
  Jesus Christ, can this meme die already?

CyberDildonics 4y ago

LuaJIT should be much faster than javascript Also how slow is still ok? People can talk about things that aren't 'performance sensitive' but at some point it's going to matter. If a program is serving up web pages, that's an interactive application and people are waiting on the program.

winrid 4y ago
Even a slow framework is still fast for humans. My Django site renders the homepage in 10ms, and django is kind of in the realm of Rails performance wise. It's all about cost, really. But you can just tell Nginx to cache pages and then it's not a problem for the vast majority of use cases.
- ksec 4y ago
  Oh well if all the Rails site could render a medium size App with 10-20ms response time then no one should be complaining.
  - winrid 4y ago
    Well if you start fetching thousands of objects without projections and maybe make a couple writes per page load then yeah, it's gonna be slow.
brokencode 4y ago
JavaScript is so much more widely used for so many applications that it’s hard to justify LuaJIT, even if it is faster. They’re both much faster than most scripting languages like Python and Ruby. If JavaScript really isn’t fast enough, then I think you should be thinking about something like Go or Rust instead. LuaJIT is an incredible piece of technology, but in this performance tier JavaScript has won out due to sheer ubiquity and the size of its ecosystem. Edit: I never said slow was okay. I’m not advocating for slow, I’m just saying that the target audience for RJIT is developers who are already using Ruby. For significantly better speed, you probably want to look elsewhere.
JohnBooty 4y ago
Also how slow is still ok? People can talk about things that aren't 'performance sensitive' but at some point it's going to matter Done a fair amount of Rails perf tuning over the years. One of my favorite things to work on. "Fast enough" for me, is when your web framework is nowhere near your bottleneck. On your average web app endpoint you're probably spending 95-99% of your time on external calls to Redis/Postgres/etc and Postgres is probably your specific bottleneck. For these apps, Rails is most definitely fast enough. You could rewrite your app layer in well-tuned C or assembly and guess what, it's getting maybe 1-5% faster if you're lucky. Maybe you get from 100ms down to 95ms and all you had to do was rewrite 100,000 lines of Ruby in 200,000 lines of C. For other cases, obviously, maybe Rails is your bottleneck. Maybe you're providing a read-only API and everything is cachable in RAM. Rails will be fast, maybe 10ms per request, but a faster framework can spew out responses in 2ms and now you have 5x the capacity and your P95s during peak hours are really smoothed out.
- ksec 4y ago
  For Rails as an API? Yes. There are plenty of examples where Rails as an API, and specifically not using ActiveRecord, gets you 10ms response time excluding DB. But most of the Rails app, especially those with ActiveRecord and Server side rendering spend 60+% of response time, And in many cases even higher before hitting DB. And they fall into 100 to 200ms response time category.

ecshafer 4y ago

Performance is a weird metric for a web application. You can say Go or Rust will be more performant than Ruby or Lua, sure. But with web applications so often your performance has nothing to do with the language or hiccup. But you aren't just processing N requests and spitting out a response, you are communicating with other services and databases. IO is almost always a bigger source of latency in response than language speed, until you have a large enough service where you can start to worry about those small issues. Before the Developer performance matters more.

wiseowise 4y ago
Jesus Christ, can this meme die already?