Comment by rubymamis
1 year ago
Hi! If you click on the "More details" button, you'll see the following table[1].
Here's the methodology (also available on the website):
1. Loading time: Fully loads the entire text and ready to scroll.
2. Memory use after load: Memory used by the app after loading the text.
3. Scroll jump: How fast the app scrolls when dragging the scrollbar to a far position.
4. Resize: How fast the app resizes after scrolling to the middle of the text.
5. Select all: How fast the app is at multiple operations: Select all text, cut, paste, undo, redo.
6. Editing: How fast the app is at typing at the middle of the text?
7. Memory use second time: Memory usage after doing all the above operations multiple times.
8. Binary size: Binary size of the app.
9. Cross-platform: Can the app run on Windows, Linux and macOS?
I think these are very fair benchmarks. And objectively speaking, both Bear and Craft didn't perform well (well, Craft couldn't load the text since it has a limit on the amount of paragraphs it can load).
EDIT: Just noticed you signed up! Thanks for that! BTW, I did try Anytype's iOS app and it was very smooth compared to the web/Electron one.
Huh - it was surprising how poorly Bear fares in that benchmark given I use it regularly and find it snappy and responsive. But then I looked closer and saw you were loading War and Peace into it.
I'll let you in on a dirty secret: Most of my documents aren't as long as war and peace. I care a lot more about "normal" document sizes and real world typing latency. Is Anytype actually slow in this case?
My benchmark is largely based on the "Moby Dick Workout"[1] of Jesse Grosjean. I agree with him that ANY text editor should pass these tests. And block editors are first and foremost text editors. I just decided to take it up a notch and do my tests on War and Peace.
Another very crucial point, a good deal of software today is written with no oversight on performance at all, so you end up needing to buy the latest hardware to run apps smoothly. Why would anyone need a M3 Macbook to run a text editor fast??
This is why I used a 2017 Macbook Air in my tests and not the M1 Pro next to it. Efficient software matters for the longevity of hardware.
[1] https://www.hogbaysoftware.com/posts/moby-dick-workout/
Yeah thats fair. I have a friend building a personal thought management system, like roam research. Her goal is to store everything she thinks in her life.
In the 8 years or so she's been working on it she's recorded about 100k thoughts. So, 1 million thoughts is probably enough to store everything you think in an entire lifetime. Thats a bit of a grim thought, but its probably about the right performance target for something like that. There's something very calming about knowing that if it performs well with 1M thoughts, its fit for purpose.
Its nice to have benchmarks like that.
For what its worth, I'd recommend explaining all of that with the benchmark explanation. "Measured on a 2017 macbook air with the text of War and Peace". Seeing Bear crash doesn't really tell me enough about whats going on.
1 reply →
do you also have vim support? This is crucial for me
I'm sorry, I've never used vim. What does vim support inside a block editor means?
> What does vim support inside a block editor means?
Users who care deeply about note taking want don't want to learn a new set of keyboard shortcuts and movements. Apps like Logseq and Obsidian (and many others) either support Vim-style movements out of the box or they're available as a plugin. Same thing with Emacs-style shortcuts and Org mode.
Folks have been using these editors for decades and they want to use their muscle memory everywhere they enter text.
Depending on the user and the use case, the lack of Vim or Emacs support ranges from a minor annoyance to a show-stopper.
I’m guessing, at the very least, vim cursor movement as described here:
https://vim.rtorr.com/
1 reply →