Performance Mode (Database Editing, File Storage)

Feedback Feature Requests
1

I was chatting with @andotvu in the Discord about the possibility of a database-centric performance mode for Logseq.

As it stands, my only complain with Logseq is the constant editor lag, which is an issue with how Logseq writes to files. I find that it tends to break my flow and thought-stream quite often - every millisecond counts with tools for thought!

This will be improved with the upcoming editor refactor, but since Logseq is an outliner with advanced features and data manipulation, the performance will never be as good as Obsidian when writing directly to files. Yes, Obsidian can do amazing things, but at the end of the day its just a text editor. Logseq is different.

I am envisioning the ability to turn on a “performance mode” that allows for editing to be done via database for high performance, while still keeping the focus on file storage. This would be via cloud db on web, or local db on desktop.

With performance mode activated, there would either be a way to sync to local files, or the system could automatically operate via database when editing, and then write to files when not editing. The latter would probably be the way to go imo.

As long as the focus remains on transparent local files and portability, I think a db/performance mode would be a great addition.

2

This post resonated a lot, specially this part:

I’m really invested in Obsidian and I love what is being done, but Logseq has the potential to be a user-friendly powerful variation of org-mode, which covers the holes of what Obsidian is not.

However speed and stability in Logseq can certainly improve, of course we have to be fair and hope this is something that will come as this tool keeps growing.

This idea is great.

Anything that can make the process smoother and stable would make it possible for more people to give Logseq a try and stay with it for the long run.

1 Like
3

Yeah I didn’t even really consider a database mode like this because I, like many others here, really like the transparency of a files-only approach, and in my mind it’s been an either/or situation (database vs local files).

Then I saw a mention of a db-only mode in the Discord and it got the gears churnin’.

There is no reason why we can’t have the best of both :slight_smile:

Why not have a database that does the heavy lifting and caching, with transparent files being the storage mechanism.

3 Likes
4

Isn’t this how it already works? Logseq uses datascript. What they want to achieve is to use DB to store notes data all the time to make it work with multiple users sharing the same data (I assume this will work as a service on their servers to get some money from this great project) and have an option to store notes on hard drive for those who want to use it privately, this is what I understood from this discussion on discord.

5

Yes, I think you are correct in that it already does use a database.

Though my infantile understanding is that it directly writes to files in real time while editing.

I get constant lag while editing, whether its typing, selecting, dragging, etc.

So what I’d love is that if there was no file writing while doing these actions, but that the file writing would happen after the actions are done.

And yes, you are correct - the team’s vision of an all-database mode would be for enabling remote collaboration, publishing, etc.

What I’m proposing here would be in between that vision and the current reality.

So something like three modes:

  1. Normal Mode (write directly to files - offline)
  2. Performance Mode (process/cache in local db, periodic write to files - offline)
  3. Collaboration Mode (process/cache in cloud db, optional sync to files - online)
2 Likes
6

It does not, it waits until you stop writing and then some. Can’t locate where is this part in the code, but it’s clear when you test this, you can check modification time before and after you write something, you can see it doesn’t change if you’re quick enough. Or just look at your commit history, you don’t see there commit for every letter, but for entire sentences - same happens with writing to files.
I see that lag too, but always after the action is done. There is no reason for that lag to exist, it looks like currently it’s simply blocking main thread, but it’s possible to do that in the background. Storing stuff in some DB on hard drive would do the same thing with current approach.

It might be also not the problem with reading and writing files, but with pure transforming data from objects that are stored in memory to plain text. That too can be done in background. Or at least it was possible in the past, Electron constantly evolves and I didn’t work with it for years. I don’t have access to the old code, but IIRC the way to not block UI with heavy calculations was to create second window, not visible to the users, and move the data between them - UI stuff done in the main visible window, saving and calculations in the invisible window.

1 Like
7

side question: Do you know where is the discussion or development of multiuser version? Can’t find much on this. I really need this.

8

I would be up for a “database-only” mode if it can increase performance. I don’t care so much about keeping text files in sync. I think an “export notes to Markdown” function would be sufficient for me.