I've got a suite of CSVs that represent both edge case and performance issues, and I script timing opening/common operations using Apple Scripting. It's not perfect, but it gives us a sense if we're introducing back-breaking regressions. I try for our large files to test specifically with real-world, large data dumps from US government sources; I feel these are representative of actual large-CSV workloads. You can see me popping off about it on bluesky: https://bsky.app/profile/wyattkirby.com/post/3mnfvma4cgk2g
We're not necessarily aiming to be the fastest application in the world; find/replace is probably still faster to just do sed in the terminal. But if you're looking to do something like sort, filter, actually engage with the tabular data, then we can handle hundreds of thousands of rows --- files that excel won't even open.
I'll take a look at blackbear. One core difference I see is that we're a native app, fully offline. There is a single handshake with the licensing server on app start, but it's optional. License validation is handled fully locally, and missing network access is non-blocking for any features.
We're not necessarily aiming to be the fastest application in the world; find/replace is probably still faster to just do sed in the terminal. But if you're looking to do something like sort, filter, actually engage with the tabular data, then we can handle hundreds of thousands of rows --- files that excel won't even open.
I'll take a look at blackbear. One core difference I see is that we're a native app, fully offline. There is a single handshake with the licensing server on app start, but it's optional. License validation is handled fully locally, and missing network access is non-blocking for any features.