These sorts of numbers need very careful understanding and analysis, otherwise they can be misleading. It isn't comparing apples to oranges to measure the performance of FoundationDB transactions vs an RDBMS.
A FoundationDB transaction is a vastly less powerful thing than an RDBMS transaction. In particular, an operation that would be one transaction in an RDBMS must often be split into several transactions in FoundationDB due to its timeout and size limits. An RDBMS allows a client to take thinking time for as long as it needs whilst working on a transaction. FoundationDB stores its undo logs in RAM rather than on disk. This lets them advertise great latencies but is the cause of the five second timeout. They actually advertise this as an "anti feature":
And KV stores suffer the N+1 query problem once you go over the network: traversing links between objects/joins requires round-trips through the client unless you have a very smart record layer and only do simple traversals, which can immediately kill your latency. But in FoundationDB higher latency = smaller numbers of possible operations before your transaction expires and has to be retried from scratch. Thus you can get into a situation where the cluster slowing down due to network congestion can cause death spirals in which transactions start dying because they ran out of time, get retried by the client and this places more load on the cluster which then slows down even more, etc. Whereas in an RDBMS the database slowing down causes backpressure to the clients that is ultimately propagated to the user, avoiding this kind of problem.
So... database benchmarks. Complex thing. Be careful out there! See my other comments on this thread for disclosures and more discussion of RDBMS vs FoundationDB.
Which is why I said it probably scales well. But you can not equate that with per query performance. Accessing rows over the network is a few orders of magnitude slower than local NVME disk with big RAM caches.
Looks nice, I wish you best of luck! I personally haven't seen my "new tab" page in a very long time. What I'm doing instead: in current tab hit Cmd+L to focus on address bar, type query/address hit Option+Enter to open resulted page in a new tab. Skipping a bunch of clicks and the "new tab" page. Should be Ctrl+L Alt+Enter on Windows.
I'm curious: is there a particular reason for this very specific workflow? Is there an advantage I'm not seeing over Ctrl+T, type url, press Enter? Or is it just the way you do it?
Just something I got used to do. My right palm is always conveniently hovering above the right Ctrl, Alt and L, Enter keys, making those combos easy and instant.
After hitting Ctrl+L, I usually do one of these: 1) "Enter" to discard current page; 2) "Alt+Enter" to open in new tab; 3) "Ctrl+Enter" to open in new tab but keep focus on current page (e.g. read later); and 4) "Esc" if I got an answer from the address bar (math, currency, history, already open page, etc).
> Is there an advantage I'm not seeing over Ctrl+T
My own experience is that all of the times I press Ctrl+T is to open a new tab to enter a location I want to navigate to; I don't care much for what the new tab displays (this is why I set my default new tab to a blank page), and if I did, it would probably be a distraction.
That "type of worklofw" is the main workflow. The difference is that he is using a shortcut rather than clicking URL bar. U dont always need a new tab.
If you like saving clicks, maybe the new tab page I've been using for years might interest you[0]. I like being able to just open a new tab and go to a page with a single keystroke, so I threw this together years ago to let me define a custom list of shortcuts that I can jump to by hitting the key of which index the site I want (originally I had used a Chrome extension that did something similar, but when I switched to Firefox and couldn't find anything similar enough that I liked, I realized it would be fairly easy to make as a static page that would work on any browser).
I built a chrome extension to optimize this workflow, because the address bar search in Chrome is terrible (as in: it requires you to @-mention what kind of thing you're searching for.)
Ctrl-T opens a new tab page, <tab> highlights the search bar, and then I get instantaneous search over open tabs, bookmarks, and history. Everything stays 100% local.
You could simplify it a tiny bit by using Ctrl+T to open a new tab and simply entering the query there, then pressing enter. Saves you the combo on the second hotkey.
there was a time when I configured my mouse to have buttons for ctrl+w, ctrl+t, ctrl+shift+t, ctrl+tab and ctrl+shift+tab and I actually used them... until I had to use another mouse on another computer
I'm on light mode by default. If you look at the "The fullstack database" text you'll see things emanating from it outwards. Fast, and barely visible, hence the initial confusion. In any case, it's not a problem at all, just caused me doubt my vision for a moment :)
Robust undo/redo remains an ongoing research project. Leo Stewen's work was presented at PLF 2023 a few days ago. It turns out to be a subtle problem to really get completely right, but in my experience you can usually get passable results by letting editors default undo behaviour reverse text input.
For applications with more document-structured data, you can now produce inverse patches using Automerge.diff to go between any two points. To implement a reasonable undo in this environment you can record whatever document heads you consider useful undo points and then patch between them.
To perhaps expand on why the problem remains unsolved slightly further, there was a robust discussion about what the expected behaviour of "undo" out to be in even simple cases at the conference.
I share the frustration! I have to open lots of small and large CSV files daily, with multiple encodings. Usually I'm juggling between Excel, Numbers, and Sublime text editor - depending on which one would open that file faster.
Naturally, I installed Modern CSV seconds after seeing this post.
I'm on MacBook M2, using trackpad 1) the vertical scroll is slow and un-mac-like, unnatural; and 2) horizontal scroll basically doesn't work, it scrolls a column or a half on a full swipe, but it does improve somewhat when there's less content in the cells.
I admire your work, please keep on going, there's a huge need!
Looks like it's scrolling in general, not just trackpad. It appears to limit the maximum scroll speed when I'm using a mouse. I take it this is because the app is programmed using some kind of non-native controls?
I noticed on Windows that if I have the window in focus and scroll, each notch of my scroll wheel scrolls 4 rows. However, if I have another window in focus and hover over the Modern CSV window and scroll it will scroll ~90 rows (not always the same for some reason). The max scroll speed is the same in both scenarios, which I tested using a free-spinning scroll wheel. After some more testing it seems a lot of programs handling scrolling differently between these two scenarios, but it is much more obvious in Modern CSV because a single notch scrolling 90 lines is quite a lot.
I would like to be able to have some kind of scroll options available, choosing between smooth-scrolling or scroll by row/column would be great. Removing the scroll speed limit would be good too.
According to an old report, FDB can do around 75k transactions per core [0].
MySQL on same CPU (all cores) can do about 8k [1].
[0] https://apple.github.io/foundationdb/performance.html
[1] https://www.anandtech.com/show/8357/exploring-the-low-end-an...