Thread by @TfTHacker

1/6 @logseq deep dive continues... today some words on performance.

Some time back, I did a performance test on Logseq, but it didn't pass my expectations. Many graph DB-based Tools for Thought didn't do so well in the past. #TfT

However, things have changed for the positive.

2/6 I know engineers always intend to make speed a priority, but the truth is, early in the development process of a new TfT, it's easy to skip that part and focus on rapid iterations of features.

It is a tough balance to strike: new features that users demand and speed.

3/6 Most users don't notice this since they start with a small collection of notes & slowly add. But, as the months pass into a year or so, performance becomes a big issue.

When users notice it, they really notice it & rebel. Performance is a big reason people will switch tools.

4/6 I'm happy to report that Logseq did well in my testing. I know they have put forth the effort to improve performance, and it shows.

Interestingly, block count matters more, not so much file size.

That is why I focus on large block counts.

5/6 My test is not scientific, but it's based on the responsiveness of the UI:
+ Saving
+ Block referencing
+ Number of backlinks
+ Invoking features commands
+ command bar navigating through pages/blocks
+ Page loading with a high block count

6/6 What matters for day-to-day use (battle in the trenches) is the app load time and responsiveness while typing in blocks and invoking commands.

I am satisfied with Logseq's performance for everyday use and pleased to see this is important to the Logseq dev team.