Poor performance on very large files

[jamiemcg]

Currently the live preview, status bar, word count are updated after every key stroke. Better to add delay or limit.

This is related to #5

[vphantom]

I'd like to add that, if the webkit API you're using allows it, it would be very useful to force caching of network resources (images) for a minimum amount of time. I'm often using Remarkable to edit GitHub README files which include build and coverage badges, which end up being reloaded from network after every few keystrokes.

If the API doesn't give you this level of control, then perhaps an option to toggle the displaying of images and other external resources in the live preview could do the trick. I'd disable it during heavy editing, and enable it for final review or light edits.

(Also, quick note: I usually look at the live preview, not the editor, while I write text, so if the live updates themselves became less frequent, I would lose this "WYSIWYG" benefit.)

[mdouchin]

+1

When using the live preview feature, Remarkable eats CPU when typing fast. It is noticeable, because it slows down the writing of the characters in the left panel (raw text). Sometimes, it even prevents me from typing.

I think an easy solution could be to wait for N chars typed, or for N seconds before refreshing the live preview. "Live" does not need to be "microseconds live". I am confident many users would find it acceptable if "live" meant "Every N seconds".

Havind an option to set this N could be good too.

[sergiodlc]

There are several ways to mitigate this issue. Probably the easiest one would be to move the rendering of the Markdown text to another thread with some kind of a signaling mechanism to avoid rendering the whole thing while a previous rendering is in progress along with some delayed rendering logic.

Threads, however, are not the best solution here, since Python has the infamous GIL, which would prevent both threads from actually running in parallel. It would help, nonetheless, because the scheduler would be able to share the processor between both threads, removing the lag while typing in the UI thread.

BTW, I made some tests the other day, when I saw that the rendering was in the UI thread to double check what I imagined would be a bottleneck. So I downloaded the whole text of the Bible and tried to open it with Remarkable. I had to kill the process because it became completely unresponsive. I then tried with a smaller document (The Petit Prince). It didn't become completely unresponsive this time, but it would only allow me to type a character every couple of seconds or so, which made Remarkable virtually unusable with the Live Preview on.

Other possible (better) solutions for this issue:

1. Do the rendering in a forked process using the multiprocessing module or something similar and handling the communications using IPC.
2. Use a C/C++ Markdown renderer with Python bindings and have it do the rendering in a separate thread. This alone would speed up the process big time, since the current renderer is implemented in Python. Even better if that compiled component would do caching and multithreaded rendering itself, since compiled extensions are not subject to the GIL. Not sure, though, if such a library exists and how well would it play with Remarkable.

@jamiemcg, If you are OK with this, I can prepare a pull request for moving the rendering to a separate thread using the current python-markdown module.

[knzudgt]

I would suggest to give the opportunity to toggle the live from preview, and give the user the choice to choose between a live preview for small documents and a preview refreshed only when the buffer is saved to disk for large files, like in Atom.