5 ms·
Do you really need concurrency? My understanding is read are like… picoseconds, because everything happens in memory. You don’t have a separate server to call.
by adenta 2y ago
Do you really need concurrency? My understanding is read are like… picoseconds, because everything happens in memory. You don’t have a separate server to call.
This guy is great: https://fractaledmind.github.io/2024/04/15/sqlite-on-rails-the-how-and-why-of-optimal-performance/ https://fractaledmind.github.io/2024/04/15/sqlite-on-rails-t...
- adenta 2y agohttps://fractaledmind.github.io/images/railsworld-2024/111.png https://fractaledmind.github.io/images/railsworld-2024/111.p... https://fractaledmind.github.io/2024/10/16/sqlite-supercharges-rails/ https://fractaledmind.github.io/2024/10/16/sqlite-supercharg...
- tiagod 2y agoYou're off by two orders of magnitude.
- geysersam 2y agoMore like six?
- relistan 2y agoIt would be more constructive if you guys posted the correct numbers and a source.
- christophilus 2y agoA quick search suggests SSD reads are in the milliseconds. I’ve found that, or microseconds to be roughly accurate. SQLite queries, however, can take seconds (or more in pathological cases) depending on how optimized the indices are to the query being run, load, etc. This is one of the reasons I don’t love using SQLite in Bun servers. It makes me nervous that a bad query will bring down the single thread of the app.
- bborud 2y agoit is easy to assume most programmers today know roughly how long things take since this has existed in various forms since Jeff/Peter first published it: https://colin-scott.github.io/personal_website/research/interactive_latency.html https://colin-scott.github.io/personal_website/research/inte... (This version is more useful since it shows change over time)
- adenta 2y agoThat’ll teach me to post first thing in the morning. Something something, Cunningham's Law.
- bborud 2y agoIt would be mice for it to work in concurrent contexts as even using mutexes adds responsibility (for not messing up).