Repository navigation
Extreme Performance Issues With Long Notes #2489
Description
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:
- Create a new note
- Switch to plain edit mode
- Type some text (anything works)
- Select everything and copy it
- Paste text several times
- Attempt to type anything
- 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
Activity
joshtrichards commentedon Nov 18, 2024
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 commentedon Nov 18, 2024
The size of the note is 81 kb, according to the Files web UI.
According to
wc, here are some additional metrics: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)
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:
splintering commentedon Aug 10, 2025
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 commentedon Jul 2, 2026
I dug into this. The regression window reported here matches the introduction of the
controller framework in
nextcloud-commons:markdown2.x:MarkwonMarkdownEditor. onSelectionChanged()callsnotifyControllers()on every keystroke, andEditorStateNotifier.notify()created two new ExecutorServices per call (one of thema thread pool with 10 core threads), shutting down the previous ones via
shutdownNow()— roughly 11 thread creations per typed character, plus evaluatingall 9 command states against the full content. On top of that, while in-note search
is active,
SearchHighlightTextWatcherre-applies all search spans over the wholedocument 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
commonsVersionbump here should fix this issue and #3162.The search-side fix is in #3249.
solonovamax commentedon Jul 3, 2026
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
dragnev-dev commentedon Jul 26, 2026
Looking further to the PR getting reviewed and merged. I can reproduce the performance issues editing a 56kB file on my phone. Files with lots of formatting show performance issues on smaller file sizes. I have a 84kb file with little to no formatting that performed poorly on my old phone and performs OK on my current one
perf(markdown): reduce per-keystroke work in the editor