Yeah, this would be my concern as well if I had to run it. Sure Python apps can be fast and most time is spend in IO, not compute, and if you’re running a profitable operation the exact cost of compute might not matter much. However if you’re running a non-profit service and you want it to be as dirt cheap as possible so it can be free for most users, then the cost of compute very much does matter.
Comment on What features are missing from piefed, or, why aren't we reccommending piefed instead of lemmy?
Sibshops@lemm.ee 2 days agoI second this. Lemmy is written in Rust where as piefed is written in Python. When it comes to running a high-performance webserver, Lemmy has the advantage.
avidamoeba@lemmy.ca 2 days ago
rglullis@communick.news 2 days ago
If you want it to be “free to most users”, the cost of data storage and IO will completely dominate over the cost of CPU.
There are plenty of good arguments to prefer Rust over python for a distributed application, but “language efficiency” is not one of them.
Anyway, if you are biased in favor of Rust and want a decent argument to justify it, I will let you use ‘It’s easier to compile Rust to WASM and have the application run on the browser, while compiling python in a cross-platform way is a nightmare’, free of charge.
nickwitha_k@lemmy.sdf.org 1 day ago
Ease of cross-compiling is really one of my favorite things about Rust. It can run anywhere with little coaxing needed.
poVoq@slrpnk.net 2 days ago
While theoretically true, the main bottleneck with Lemmy seems to be the database performance, so with both projects depending on PostgreSQL for that, I somewhat doubt that Piefed being written in Python will have much noticeable effect in reality.
msage@programming.dev 2 days ago
Postgres is so quick if you know how to use it…
nickwitha_k@lemmy.sdf.org 1 day ago
You don’t even need to know how to use it very well, in my experience.
msage@programming.dev 1 day ago
Really depends on many factors. If you have everything in RAM, almost nothing matters.
If your dataset outgrows the capacity, various things start to matter, based on your workload. Random reads need to have good indices (also writes with unique columns), OLAPs benefit from work_mem, >100M rows will need good partitioning, OLTP may even need some custom solutions if you need to keep a long history, but not for every transaction.
But even with >B of rows, Postgres can handle it with relative ease, if you know what you’re doing. Usually even on a hardware you would consider absolutely inadequate (last year I migrated our company DB from MySQL to Postgres, and with even more data and more complex workflows we downsized our RAM by more than half).
nickwitha_k@lemmy.sdf.org 1 day ago
Postgres being a bottleneck is a first for me. Not saying it’s not possible, just… It’s postgres. Wondering if it’s more an issue with ORM, etc.