141–150 of 158 posts
Earlier quoted context omitted.
That’s not easy to answer, because it’s not quite an apples to apples comparison if you start factoring in libraries, frameworks and the specific workload. My rule of thumbs: Python has similar performance characteristics as Ruby. With Java/C#/Go you’d expect about an order of magnitude of improvement. With naive Rust/C++ you would likely be at the same average speed as Java for web applications but with less memory…
Node.js is about 20x faster than RoR for instance
Earlier quoted context omitted.
That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture
> The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. Most companies don’t have unlimited budgets. Performance-oriented organizations profile and then spend money where profiling tells them to. Shopify isn’t hiring people to contribute to MySQL or Redis internals. They hired a full team to work on Ruby internals, not just creating YJIT,…
The bizarre part here is that anyone who paint themselves into a corner with ruby, then decide that they need to implement an entire new fancy VM instead of just find targeted bottlenecks and rewriting them in C++. They writing complicated native programs to make a VM that is only 15% faster when they could rewrite specific sections that are slow and speed those up by 200x or more.
Earlier quoted context omitted.
Swap is horribly expensive and most hyperscalars run their servers without swap and set per-process memory limits, automatically killing workloads that go above their threshold..
swap is only expensive if you are using the swapped out memory. if you are in a case where a program is just holding on to pages it isn't using, swap is basically free. for most users, turning off swap is just losing performance since the OS can always use all of your RAM to cache disk access.
Zswap is always performance increasing. Swap to disk can be performance degrading (good implementations generally are not unless your working set is larger than your memory and you’re in thrashing) and certainly expensive $$ wise in that it wears out your SSD faster.
You seem to be thinking I’m arguing in absolute terms where all I’m saying is that swapping is a more expensive technique to try to reclaim that unused RAM vs the memory allocator doing it. It can be a useful low-effort technique, but it’s very coarse and more of a stop gap to recover inefficiencies in the system at a global level. Global inefficiency mitigation is generally not as optimally effective as more localized approaches.
Consider also that before the OS starts swapping, the OS is going to start purging disk caches since those are free for it to reload (executable code backed by file, page caches etc). These are second order system effects that are hard to reason about abstractly when you have a greedy view of “my application is the only one that matters”. This means that before you even hit swap, your large dark matter of dirty memory sitting in your allocator is making your disk accessed slower. And the kernel’s swap doesn’t distinguish working set memory from allocator so you’re hoping inherent temporal and spatial locality patterns interplay well so that you’re not trying to hand out an allocation for a swapped out block too frequently.
Earlier quoted context omitted.
Please listen to the Github engineers in the provided links. > We forked rails and _practically wrote our own._ We fought against the framework. We deviated from the framework, and we even wondered if rails was right for us at all. and > Rails 3 was found to be five times slower than Rails 2
> Please listen to the GitHub engineers I regularly talk with engineers that worked on that project at GitHub, some are now my coworkers. I know more about this effort than what was said publicly. > Rails 3 was found to be five times slower than Rails 2 This is a bogus claim. It might have been 5 times slower on some pathological cases, it absolutely wasn't 5 times slower overall.
Earlier quoted context omitted.
> Please listen to the GitHub engineers I regularly talk with engineers that worked on that project at GitHub, some are now my coworkers. I know more about this effort than what was said publicly. > Rails 3 was found to be five times slower than Rails 2 This is a bogus claim. It might have been 5 times slower on some pathological cases, it absolutely wasn't 5 times slower overall.
The presentation and "bogus claim" is from a principle Github engineer and core Rails team member. I will trust them rather than anonymous anecdotes.
You are interpreting both links you gave in terrible ways.
Earlier quoted context omitted.
The presentation and "bogus claim" is from a principle Github engineer and core Rails team member. I will trust them rather than anonymous anecdotes.
I'm a Rails core member too, and Eileen is my colleague... You are interpreting both links you gave in terrible ways.
It sounds like you’re seeing the pain GitHub suffered through rose colored glasses. The talks about GitHub Rails upgrades say it took years and caused burnout.
Earlier quoted context omitted.
I'm a Rails core member too, and Eileen is my colleague... You are interpreting both links you gave in terrible ways.
I’m quoting, not interpreting. What am I missing? It sounds like you’re seeing the pain GitHub suffered through rose colored glasses. The talks about GitHub Rails upgrades say it took years and caused burnout.
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, and produced longs term losses. It's a self induced problem.
In the end they upgraded and are now tracking the main branch, so the problem wasn't Rails.
Earlier quoted context omitted.
Amazon.
Amazon was founded in 1994, that's not the same era. Ruby didn't even exist back then and was released a year later. Rails was released in 2004. Shopify was founded in in 2006, 12 years after Amazon.