Much smaller user base, distributed servers, modern code (versus reddit’s ancient code), less enshittification in the code (reddit’s various manipulative algorithms).
Yeah… Lemmy’s code and the way it implements activity pub is not the greatest… A lack of batch operations means that every single federated like is an HTTP request of its own.
My favourite is having to send the activities sequentially, meaning you can very easily block the queue when a request fails.
And that’s just the network architecture. Database architecture is another kind of hell. Like a simple delete operation taking multiple minutes because there’s a multitude of triggers, some of which take very long. That in itself is not bad, but the fact that the api waits for all the operations to succeed or fail (or the more usual case, timeout) is bonkers. Either fix the db or do it in the background.
I was excited for Lemmy a year and a half ago, which quickly passed. Thinking of migrating my server to some alternative. If Sublinks launches eventually, I’m migrating in an instance, currently thinking of writing an api compatibility layer between Lemmy and Piefed to migrate without anyone noticing.
It’s probably down to how much random crap is being loaded along with what you’re trying to see. The modern web means page load takes forever, in part because of all the random things your browser also has to pull down. Some of this content need to be loaded before you can render much of anything and some of that will result in calls to yet more random servers. Look at the network tab in your browser’s dev tools to see what I’m talking about. Without an ad blocker you’re probably looking at calls to 10-20 servers just to load a webpage.
The old reddit API was actually pretty snappy, in part because it didn’t need a lot of this overhead. I suspect the same is true for Lemmy - no extra fluff.
Much smaller user base, distributed servers, modern code (versus reddit’s ancient code), less enshittification in the code (reddit’s various manipulative algorithms).
Eh, the code is very inefficient.
Yeah… Lemmy’s code and the way it implements activity pub is not the greatest… A lack of batch operations means that every single federated like is an HTTP request of its own.
My favourite is having to send the activities sequentially, meaning you can very easily block the queue when a request fails.
And that’s just the network architecture. Database architecture is another kind of hell. Like a simple delete operation taking multiple minutes because there’s a multitude of triggers, some of which take very long. That in itself is not bad, but the fact that the api waits for all the operations to succeed or fail (or the more usual case, timeout) is bonkers. Either fix the db or do it in the background.
I was excited for Lemmy a year and a half ago, which quickly passed. Thinking of migrating my server to some alternative. If Sublinks launches eventually, I’m migrating in an instance, currently thinking of writing an api compatibility layer between Lemmy and Piefed to migrate without anyone noticing.
It’s probably down to how much random crap is being loaded along with what you’re trying to see. The modern web means page load takes forever, in part because of all the random things your browser also has to pull down. Some of this content need to be loaded before you can render much of anything and some of that will result in calls to yet more random servers. Look at the network tab in your browser’s dev tools to see what I’m talking about. Without an ad blocker you’re probably looking at calls to 10-20 servers just to load a webpage.
The old reddit API was actually pretty snappy, in part because it didn’t need a lot of this overhead. I suspect the same is true for Lemmy - no extra fluff.