Re: maybe it's time to re-consider server-side inefficiency
"I think BB's point was that if you were losing performance from Meltdown mitigation you might be able to "reclaim it elsewhere by optimising userland."
You mean like replacing shitty devs that can't write efficient SQL if their life depended on it. That will never happen, because that other dev who can do that actually costs $$. You can have 3 shitty devs for the price of one good one.
This is not a technical issue, this is a management issue (or a lack of having a competent one)."
This is how I interpretted his response. Although for different reasons that you've pointed out.
There is a tendancy now, as we're in a "golden age" of server performance to allow sloppy coding and/or coding decisions to be made, which are hidden by the super duper speed of the server the application/code is running on.
Back when I started in web development I was still on dial up and I didn't know many people who had ADSL or even ISDN. So when I coded websites they were optimised to load as quickly as possible on poor internet connections. Now though, while I still work in that mentality, there are developers who are either fresh out of university or get hard on's over the next new cool thing who load sites and applications with bloated shit that doesn't do anything more than make something pop up from the bottom of the screen. They've never had to develop for slower connections, or they simply think that because everyone should be on faster internet connections that their bandwidth can handle the bloat they're adding.
But if you say that in a public place, like BB and myself did, those voting down who are offended the most are the ones most guilty of such crimes.