Severe performance issue when writing long form articles.

[omenking]

One way I am bringing an audience onto my platform is by writing long-form articles on cloud vendors.

When my article starts to get long I start to experience slowdowns where I have to wait for typed letters and my Macbook Pro also begins to heat up.

It makes me think that its something that is watching on every keypress.

I turned of Grammarly, reduced to a single tab in Chome and tried Firefox, and it was still a problem.

I moved my article over to Hashnode editor, and finished it there with no problems.

This is a draft article on Hashnode if you want a see of length.

https://hashnode.com/preview/60fd9a0e31552277811af87c

Its not a big deal since I can just write my long form articles on Hashnode and cross-post, but it will make it hard for users to author long articles.

[github-actions]

Thanks for the issue, we will take it into consideration! Our team of engineers is busy working on many types of features, please give us time to get back to you.

Feature requests that require more discussion may be closed. Read more about our feature request process on forem.dev.

To our amazing contributors: issues labeled type: bug are always up for grabs, but for feature requests, please wait until we add a ready for dev before starting to work on it.

To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @forem/oss. The OSS Community Manager or the engineers on OSS rotation will follow up.

For full info on how to contribute, please check out our contributors guide.

[omenking]

It's also a problem for short articles as well:
You can see me type an entire sentence and I'll have to wait a long for it to appear.

https://youtu.be/ptPpzyBxwWY

I have not investigated if it's server-side or client-side or a combination of both.
It is my guess currently that it's client-side issue and maybe there is a population of observers or events watching.

[cmgorton]

Thanks for bringing this up @omenking and adding more context. I am currently unable to replicate but I'll share this internally to see if anyone else is experiencing this delay.

[cmgorton]

Adding in that both @omenking 's and I are using MacBook pros and Chrome. They can replicate this issue on DEV and I can't replicate on DEV, forem.dev or their Forem thedev.cloud. Their computer specs in case it is relevant for this issue:

My specs:

I have twice the memory on my computer.

[omenking]

How to replicate

I am using Chrome.

The problem compounds when you flip between Edit and Preview.
The longer the article and the more complex, the faster it impacts performance.

Alternative Machine

I have a more powerful Windows Machine with 16 GB and I could replicate
the issue but I had to pull one my largest articles and I hat flip between Edit and Preview mode for several minutes, and even then the performance issue just felt like slow typing, not full-on delays.

Thoughts

I think this could be a garbage problem where js objects are not being released or destroyed on the toggle.
I think this will be hard for someone to replicate unless they have a similar machine in terms of computing and memory.

I don't experience problems with any other kind of editor eg. Hashnode, Github Comments, but only DEVs

[aitchiss]

I've been trying to reproduce this locally without much luck (likely due to the dev macbook I'm using). I tried opening and editing the same draft post on my phone (Pixel 5) too but again no luck.

It is my guess currently that it's client-side issue and maybe there is a population of observers or events watching

There are two main candidates for this:

1. The 'mention autocomplete' feature watches keypresses, checking back in the string to the beginning of the given word for an @ symbol. I've stepped through the code and checked that regardless of how many times you go forward/back from Preview, we are only checking the string once per keystroke, and we are definitely terminating the check at the beginning of the current word. So I think this isn't the culprit.

2. The way the Preact article form works is that: bodyMarkdown is held in top-level state in articleForm.jsx, then passed down to the textarea where it is used as the defaultValue for the textarea.

However... articleForm also passes an onChange handler down to that same textarea which is called on every keystroke, and that onChange handler sets the value of bodyMarkdown.

The upshot is a render cycle is kicked off on every keystroke since the defaultValue passed in props is changed. It's an educated hunch, but I suspect this is the problem (it's quite a common problem for controlled inputs in (P)react, and re-rendering the MentionAutocompleteTextArea so often isn't as trivial as a vanilla input).

Pinging @nickytonline for his thoughts on this too.

It would be great if we were able to replicate this issue locally so we could spike out if skipping the update to bodyMarkdown on key press solves the issue

[nickytonline]

@aitchiss, thanks for the ping.

I'm currently using Edge (Chromium), but I see in your video @omenking, you're using Chrome, but as @cmgorton mentioned, she's using Chrome as well, and she didn't have the issue. One thing I'd suggest trying @omenking is disabling all browser extensions in Chrome temporarily to ensure it's not a browser extension that is the culprit. I know you disabled Grammarly, but let's try disabling all extensions and see if you still have the same issue.

I saw this end of day yesterday and immediately thought of the two things you mentioned @aitchiss. I've written a long post or two recently and did not notice any degradation in performance, and I'm also using the Language Tool browser extension for spell checking/grammar, so I'll wait to see what Andrew reports back once all browser extensions are disabled.