Extreme Performance Issues With Long Notes

[solonovamax]

This issue respects the following points:

• I have read the FAQ
• I have searched for existing issues
• The issue affects the Notes Android app, neither the Notes server app nor the Nextcloud Android app.

Describe the bug

Editing long notes causes extreme performance issues, where there is noticeable input lag when typing.

This issue only occurs when using plain editing mode and not the rich edit mode. However, using the plain edit mode is a requirement for me, as I can often times experience connection drop outs.

This issue is similar to #2192, however in that issue they mentioned that it occurs when using the rich edit mode. This issue occurs specifically with the plain edit mode.

This is a regression, as previous versions of the notes app did not experience this. Later, I will attempt to determine which version introduced the regression, however I believe it was introduced somewhere in the range of 6-9 months ago (I never bothered to report it at that time).

To reproduce:

1. Create a new note
2. Switch to plain edit mode
3. Type some text (anything works)
4. Select everything and copy it
5. Paste text several times
6. Attempt to type anything
7. Repeat steps 4-6 until there is noticeable input lag while typing.

See attached video for example.

2024-11-15_10-12-55.mp4

Expected behavior

Does not have performance issues with long notes

Notes Android version

4.3.1

Notes server version

4.11.0

Nextcloud Android version

3.30.4

Nextcloud version

29.0.7

Device

OnePlus 9 Pro 5G

Android Version

14

App Store

• Google Play Store
• F-Droid
• Huawei App Gallery

Stacktrace

No response

[joshtrichards]

How large is this note file? (I.e. Check it in the Web UI of the Files app in your Notes folder). This will help us test a similar size.

From your video it looks like not tiny, but also not an incredibly large note (judging by what I can guess/estimate based the scrollbar size).

I know slowdowns happen with very large notes (this app is optimized for notes not massive documents), but notes can still get fairly large before that happens (speaking solely in terms of my own experience).

I wonder if it's specific to resource availability on the device. That might be a variable too.

[solonovamax]

How large is this note file? (I.e. Check it in the Web UI of the Files app in your Notes folder). This will help us test a similar size.

From your video it looks like not tiny, but also not an incredibly large note (judging by what I can guess/estimate based the scrollbar size).

The size of the note is 81 kb, according to the Files web UI.
According to wc, here are some additional metrics:

Bytes	83030
Characters	83030
Words	19665
Lines	2185

I know slowdowns happen with very large notes (this app is optimized for notes not massive documents), but notes can still get fairly large before that happens (speaking solely in terms of my own experience).

imo, it should be expected to handle somewhat large notes. even like if it were a couple hundred kb of raw text. It's not like it needs to render the entire document or anything. if it's searching that's slow, I can understand that. but editing it should be a more or less fluid experience even for huge documents, tbh. especially, even that it used to perform perfectly fine in an older version. (I still have yet to get around to do a binary testing to identify in which version it was introduced. I have to study for tests up until thursday, at which point I may do it. it's unlikely to happen before then)

I wonder if it's specific to resource availability on the device. That might be a variable too.

It's probably not resource availability, as my phone is somewhat recent and should be more than powerful enough (Qualcomm SM8350 Snapdragon 888, 8 GB of RAM)

---

Possible causes could be:

• re-parsing/rendering the entire markdown document every time a character is typed, with absolutely no delay to wait for additional characters
• attempting to save the document every character
• some other processing happening every character

[splintering]

I experienced the same issue today (Notes 4.4.2). My note has grown to 98 kB and is hardly editable any more. It got worse more and more during the day, but I also wrote quite a lot. 80 kB as a noticeable starting point seems valid, as I likely wrote 20% or more of the text today.

[MiMoHo]

I dug into this. The regression window reported here matches the introduction of the
controller framework in nextcloud-commons:markdown 2.x: MarkwonMarkdownEditor. onSelectionChanged() calls notifyControllers() on every keystroke, and
EditorStateNotifier.notify() created two new ExecutorServices per call (one of them
a thread pool with 10 core threads), shutting down the previous ones via
shutdownNow() — roughly 11 thread creations per typed character, plus evaluating
all 9 command states against the full content. On top of that, while in-note search
is active, SearchHighlightTextWatcher re-applies all search spans over the whole
document synchronously on each text change.

I opened stefan-niedermann/nextcloud-commons#436 which reuses the
executors, coalesces notify requests and debounces the search re-highlighting. Once
released, a commonsVersion bump here should fix this issue and #3162.
The search-side fix is in #3249.

[solonovamax]

I would also like to note, that due to upgrading my phone (old one went kaput) (now on GrapheneOS, Android 16, Google Pixel 10 Pro), I am no longer able to reproduce with the same file, and instead need a substantially longer one