Memory leak and huge ram usage on big files

[fodrice]

OS Version: gentoo linux VNote Version: VNote-1.22-x86_64.AppImage

How to Repro: You need one big .md file outside the notes folder. I used this one (copy paste multiple times from wiki "Elephants"): Elephants killing markdown editors.zip

1. htop in terminal -> Filter -> VNote or use Memory profiling tools

2. Open big file (I'm using 30 mb file with many copy-paste from wiki).

3. Memory usage: before anything: 190mb after opening file: 375mb after closing file: 315mb after reopening: 411mb after switching to edit mode: 1221mb after closing file: 1128mb

4. Now we've got app without any file opened and 1gm ram used...

5. One more thing when copying-paste more than 0-15 thousand lines "copy as markdown" option does nothing.

And, of course 1g memory usage is too big for editor. It would be nice if it use less memory. Perhaps, loading file by parts and render only visible parts in preview could improve this.

[tamlok]

Thanks for your testing. Will dive into it soon.

[peterwx]

On Windows, I believe it has similar problematic RAM consumption issues.

I tried with a file readapted by me from a documentation page from the PlantUML website, related to one type of software architecture diagram, together with a half-dozen very small markdown files(almost all of them with their content entirely visible - not needing a significant scrolling action to reach their end). At a certain point VNote RAM usage reached 1 GB, seemingly because of very fast scrolling, but I didn't replicate this usage with recent VNote versions. But RAM usage still begins at 600 MB and possibly multiplies with each document opened.

Although in this case, I'm not certain that RAM usage is due to PlantUML or the Java runtime or VNote (WebView(s) or rendering?).

Either way, I agree with the other user and believe that partial rendering of the current screen and caching of the previous and next few, say, 5 screens could provide for better memory usage, performance and smoother scrolling and usage. A minimum delay on (PlantUML and other generators?) requests instead of instant ones - imagine the document is being scrolled very fast or to the end, so many screens( and on the limit the entire document) presumably are occupying memory unnecessarily when not being viewed/used and the renderers and generators doing wasted work. The last, most recent request(s) after the delay should be issued/received/accepted and the others discarded. Another suggestion for performance and experience optimization would be an option for retrieval of images already generated/cached from disk instead of generating them all the time on the fly with the live inline preview, perhaps requiring this preview to be restricted or disabled? Could a single WebView be reused on demand for all opened documents that need it for rendering, while all the other simpler text documents(e.g. source code and non-markdown files) would entirely forego it? Could only documents that are tab activated, be processed instead of all of them?

Are these suggestions unnecessary or even already implemented or are there some avenues for potential gains in performance and smoothness?