4 ms·

1) That ratio can be 40:1+ for a lot of use cases. That adds up in costs and if you have any other limitations (DB connections) it can be a total deal breaker.

1) That ratio can be 40:1+ for a lot of use cases. That adds up in costs and if you have any other limitations (DB connections) it can be a total deal breaker. 2) I said many gems, not Rails. Connection pooling in other frameworks is worlds better (GoLang's db package comes to mind). We're talking about now, not 2012. 3) Sure GIL is convenient when thinking about code, but the point is it makes high-scale hard. 2.1 GC is only fast by ruby standards. "Images shouldn't be served through rails" < exactly my point, other languages handle this with ease. If you are building a high-scale app you can choose 1 language+framework, or RoR AND another when things are big/hard/tough. IMO, RoR (and Ruby in general) makes easy things easier, but hard things harder. A good tradeoff for some projects, but not big or high-scale ones.

tychver 9y ago
1) I honestly have not seen a ratio that high for a web service. Most of the hot points of serving a web request through Ruby are actually written in C, so on the same machine I can only serve about 2x as many simple JSON requests through Gin as Sinatra. Once you add in waiting on IO for a DB call this gap gets narrower until it basically disappears. What blows it out to 40x? Some sort of live image/sound manipulation? If it was an inherent problem with Ruby, you wouldn't see such fantastic performance from nginx_mruby. 2) Sure, the Go connection pool is nice, but the Go ORMs are horrible as they try and work around the warts of the language. Everything's a trade-off, really. You give up terseness and flexibility for performance. 3) The GIL is definitely not convenient when thinking about code. Threads in Ruby still require you to write thread safe code. The GIL exists to make the _Ruby VM_ simpler. Otherwise you end up in the situation of Lua, where you have to re-initialize the VM in every thread and essentially have sub-interpreters, or you build something incredibly complex like the JVM. The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend. Images shouldn't be served through a dynamic web app regardless of your language. They should be served directly via a web server to a cache/CDN, even if you're generating them on the fly like dynamically composed map tiles. People pan away. They pan back. You don't want to regenerate the tile.
- ksec 9y ago
  >The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend. I have read this number of times, now one Method JIT is shown, what is the other one?
  - tychver 9y ago
    https://github.com/k0kubun/llrb https://github.com/k0kubun/llrb and https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch

tychver 9y ago

1) I honestly have not seen a ratio that high for a web service. Most of the hot points of serving a web request through Ruby are actually written in C, so on the same machine I can only serve about 2x as many simple JSON requests through Gin as Sinatra. Once you add in waiting on IO for a DB call this gap gets narrower until it basically disappears. What blows it out to 40x? Some sort of live image/sound manipulation? If it was an inherent problem with Ruby, you wouldn't see such fantastic performance from nginx_mruby. 2) Sure, the Go connection pool is nice, but the Go ORMs are horrible as they try and work around the warts of the language. Everything's a trade-off, really. You give up terseness and flexibility for performance. 3) The GIL is definitely not convenient when thinking about code. Threads in Ruby still require you to write thread safe code. The GIL exists to make the _Ruby VM_ simpler. Otherwise you end up in the situation of Lua, where you have to re-initialize the VM in every thread and essentially have sub-interpreters, or you build something incredibly complex like the JVM. The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend. Images shouldn't be served through a dynamic web app regardless of your language. They should be served directly via a web server to a cache/CDN, even if you're generating them on the fly like dynamically composed map tiles. People pan away. They pan back. You don't want to regenerate the tile.

ksec 9y ago
>The 2.1+ GC usually spends less than 1% of time in collection. That's fast by any language standard. The next step for Ruby will be a method JIT. There are two promising method JITs in development using LLVM as a backend. I have read this number of times, now one Method JIT is shown, what is the other one?
- tychver 9y ago
  https://github.com/k0kubun/llrb https://github.com/k0kubun/llrb and https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch