Very high CPU usage when typing text with HTML preview open

[ozmium]

When typing text into the editor, and the live HTML preview is open, the IDE uses a very large amount of CPU, approximately 100% of 1 CPU. This seems very inefficient.

It happens even if the "Typing update delay (ms)" is changed to the maximum of 1000 ms. This setting doesn't make any difference.

Please try to reduce the CPU usage.

Markdown Navigator, version 2.8.4

[vsch]

@ozmium, wrap on typing causes a lot of processing. There are two possible workarounds. One is to disable wrap on typing and to use document or element format manually. The other one to try setting Wrap only after space is typed in Languages & Frameworks > Markdown > Editor. This will reduce wrapping on typing by wrapping only after a space is typed.

[ozmium]

Thanks for your response. I found that the following options together (both are required):

• View -> Active Editor (markdown file) -> Use Soft Wraps = Off
• Settings -> Languages and Frameworks -> Markdown -> Editor -> Wrap only after space is typed = On

Yield an approximate 40% reduction in CPU usage. It's still fairly high though.

Coincidentally, I've noticed that the Java/Kotlin code editor in Android Studio also uses a high CPU when typing. So maybe it's an instrinsic problem.

[vsch]

@ozmium, soft wraps also add a lot of processing since the lines need to be parsed to find where wrapping occurs. However, this is done by the IDE and not the plugin.

There is a lot of processing that occurs when file content is edited. Most are done in the background which does not cause processing until there is a pause in typing but wrap on typing is something that has to be done as text is modified.

[vsch]

@ozmium, This issue could have been corrected by resolved link caching added for next release. Link resolution is very expensive in computation and was done for all links in the file when it was modified. Same links were resolved multiple times for each request. Now the links are cached and reused even between file is modifications.

This speeds up typing response and reduces cpu load so I think the next release will address this issue.

[ozmium]

This is good news, thanks.

Is it possible to offer these bug fixes for "pre 2019.2" IDEs, like Android Studio 3.5.2? The latest version of Markdown Navigator offered in Android Studio is v2.9.0.

[vsch]

@ozmium, I will only be able to back port these changes to versions of the plugin for 2019.1 and higher. What IDE build number does Android Studio 3.5.1 correspond?

I think it is 2019.1 so yes I will make a release for that. Unfortunately, it will take some effort because the number of breaking API changes from 2019.1 to 2019.2 to 2019.3 exceeds changes from 2017.3 to 2019.1.

I was able to keep a single source from 2017.3 to 2019.1 and rely on Java reflection to compensate for the changes. This is not possible for changes in 2019.2 and .3 and will either require a library to wrap the IDE API in question in an IDE version independent API or fork the plugin source for each IDE version.

Fork option will result in 3 branches for each minor IDE version of 2019 and another one for 2020.1 because the API changes between 2019.3 and 2020.1 exceed the ones between 2019.1 and 2019.3.

I tried to avoid the branched source solution because it is a nightmare to maintain, especially when there is a lot of code churn like there was for the last release. The plugin has almost 2700 modified files and libraries it uses have another 2,900.

I will most likely have to branch the newest source and back-port the changes to previous IDE version API.

It is a hard problem to address.

[ozmium]

@vsch

What IDE build number does Android Studio 3.5.1 correspond?

I believe Android Studio 3.5.x is based on IntelliJ IDEA 2019.1, as per https://developer.android.com/studio/releases#idea-2019-1

It is a hard problem to address.

No problem. We can wait patiently for your updates. Thanks for your hard work and dedication.

[vsch]

@ozmium, I appreciate your patience but our discussion made me realize that my approach of branching an old version and then trying to apply changes from the master with tons of refactored code is wrong from git point of view.

What I need to do is branch the master for an older version and then make changes to make it work with an older IDE.

Doing that will allow me to merge future changes from master to the older branch without manual intervention since all the changes for support of the old IDE are "newer" and git will not attempt to overwrite them. Making support for older IDEs painless after the initial effort of replacing new API's with code to old API's.

I don't mind the initial effort to make it work. It is the the future fix propagation from new to old branches that I cannot afford to do manually.

I feel much better about being able to support older IDEs now. I am sure 2019.1 will be supported as soon as I am done with the fire-hose cleanup of the code that I am in the process of doing now.

[vsch]

@ozmium, I got 2019.2 done today and if it goes as smooth, 2019.1 compatible plugin should be released tomorrow.

When you upgrade to the new plugin please see: #814 for upgrade to 3.0 with an enhanced features license.

Contact me by e-mail on my GitHub profile if you do not have a legacy license.

[vsch]

@ozmium, version 3.0.191.64 is released. Please let me know if the issue is resolved with the new plugin.