[rubymamis]

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.

[1] https://imgur.com/vEfV7Iq

[josephg]

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?

[rubymamis]

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/

[josephg]

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.

[rubymamis]

> There's something very calming about knowing that if it performs well with 1M thoughts, its fit for purpose.

Exactly. I've been using my note-taking app (of which Plume is built on) since 2014, so I have 4850 notes in total, and it's still rock solid and fast.

Another plus of efficient software is that my 2017 Macbook Air actually loads text ~2x faster than the best competitor (Bike) on a 2021 M1 Pro (with much more performance)

2017 MacBook Air:

Plume: 0.8 seconds

Bike: 3.46 seconds

MacBook M1 Pro:

Plume: 0.3 seconds

Bike: 1.5 seconds

That alone says a lot.

> 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.

Thanks for letting me know. Do you have a suggestion for how to convey it better?

[hruzgar]

do you also have vim support? This is crucial for me

[rubymamis]

I'm sorry, I've never used vim. What does vim support inside a block editor means?

[alwillis]

> 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.

[avtar]

I’m guessing, at the very least, vim cursor movement as described here:

https://vim.rtorr.com/

[rubymamis]

If that's what OP meant, then no. Plume will support the basic keyboard shortcuts expected from a text editor, and then some more. My previous note-taking app[1] is already very keyboard oriented, and I intend to do the same with Plume.

EDIT: Just noticed that most of the "Cursor movements" already have equivalent standard keyboard shortcuts in regular text editors.

[1] https://www.get-notes.com/