Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Note list: Slower to update in version 2.14 and 3.0 than 2.13 #10284

Open
personalizedrefrigerator opened this issue Apr 8, 2024 · 4 comments
Assignees
Labels
bug It's a bug desktop All desktop platforms high High priority issues v3.0

Comments

@personalizedrefrigerator
Copy link
Collaborator

Operating system

Linux

Joplin version

3.0.2

Desktop version info

Joplin 3.0.2 (dev, linux)

Client ID: 5cd73fa94f1c4847a76b5ee095980929
Sync Version: 3
Profile Version: 46
Keychain Supported: No

Revision: b3f4414

Backup: 1.4.1

Current behaviour

See https://discourse.joplinapp.org/t/performance-issue/37207/19

In Joplin 2.14+, the note list takes several seconds to update its sorting, while in Joplin 2.13, it was very fast.

note-list-demo.mp4

Expected behaviour

The note list sorting should update quickly in Joplin 2.14 and Joplin 3.0, as it did in Joplin 2.13.

Logs

No response

@personalizedrefrigerator personalizedrefrigerator added bug It's a bug desktop All desktop platforms medium Medium priority issues labels Apr 8, 2024
@laurent22 laurent22 added high High priority issues v3.0 and removed medium Medium priority issues labels Apr 8, 2024
@personalizedrefrigerator
Copy link
Collaborator Author

personalizedrefrigerator commented Apr 11, 2024

Likely related to/a duplicate of #10203

@HahaBill
Copy link
Contributor

First of all, great bug report! I will have a look and tell you what I've discovered.

@HahaBill
Copy link
Contributor

HahaBill commented Apr 15, 2024

Alright, I got an update: The problem seems to be in the NOTE_SORT, where there is a timeout of 2 seconds in sortNoteListTimeout. I changed it to 0 seconds, and it was immediately fast and solved the issue! However, in the comments, the purpose of this delay was stated.

if (sortNoteList) {
		if (sortNoteListTimeout) shim.clearTimeout(sortNoteListTimeout);
		sortNoteListTimeout = null;

		// We sort the note lists with two seconds debounce because doing can be
		// very slow and would have to be done every time a note is added.
		if (Date.now() - newState.noteListLastSortTime > 10000) {
			dispatch({ type: 'NOTE_SORT' });
		} else {
			sortNoteListTimeout = shim.setTimeout(() => {
				sortNoteListTimeout = null;
				dispatch({ type: 'NOTE_SORT' });
			}, 2000);
		}
	}

@HahaBill
Copy link
Contributor

Alright, I got an update: The problem seems to be in the NOTE_SORT, where there is a timeout of 2 seconds in sortNoteListTimeout. I changed it to 0 seconds, and it was immediately fast and solved the issue! However, in the comments, the purpose of this delay was stated.

if (sortNoteList) {
		if (sortNoteListTimeout) shim.clearTimeout(sortNoteListTimeout);
		sortNoteListTimeout = null;

		// We sort the note lists with two seconds debounce because doing can be
		// very slow and would have to be done every time a note is added.
		if (Date.now() - newState.noteListLastSortTime > 10000) {
			dispatch({ type: 'NOTE_SORT' });
		} else {
			sortNoteListTimeout = shim.setTimeout(() => {
				sortNoteListTimeout = null;
				dispatch({ type: 'NOTE_SORT' });
			}, 2000);
		}
	}

Oh and one more thing. NOTE_SORT is used for both notes and to-dos, that also explains the #10203

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug It's a bug desktop All desktop platforms high High priority issues v3.0
Projects
None yet
Development

No branches or pull requests

3 participants