Closed vi closed 12 years ago
Thank you for the info. I've made few optimizations for case 1 and 3. Could you please test current master and say, if it became better on your HW. Cases:
[1] CPU usage reduced from about 90% to about 60-70%; [2] Still the issue (haven't compared the amount). A proposal for fixing (complex one): Enki should detect CPU shortage and defer rendering markdown. The first time it it will stumble (measuring the rendering time), next time it will be less eager to render it. (Is it rendering markdown in a background thread?). Easier solution can be configurable delay that Enki waits after user finishes typing before rendering any complex things. [3] Resolved, now it is like in "[1]".
60-70 on Atom is OK. I won't waste more time for it
Yes, I process text in thread, but main GUI thread redraws Preview dock, and, it seems like it is slow.
I'm not sure if complex solution will work stable. Rendering time may depend on many factors, and may be very different (Now system uses swap and drawing is slow, next time it would be quick)
Easier solution is a good idea. Now I redraw Preview 300 ms After user stopped typing text. Delay is not configurable, I hope 300 ms will be ok for all users.
Looks like resolved now.
What should happen New characters appear at contact rate, CPU usage is little.
What happens Makefile: new characters appear smoothly, but CPU usage by Enki is 90% README.md: blocks of new characters appears with exponentially increasing delays, CPU usage by Enki is 100%. Closing preview pane does not speed up typing.
Hardware is EeePC with Atom N550 @ 1.50GHz.