Performance improvement

[edwh]

Thanks for the useful lib. I've seen some performance issues causing slow typing, which I can verify in the Chrome performance tab. I think this is because even if the height of the textarea doesn't change, the getting the calculated height from the element is an expensive operation.

I put in a quick hack to only do the calculation and update once a second, which is still ok for the user experience, and this seemed to help me.

[ghost]

With CPU throttling 6x in Chrome Dev Tools i see only few lags with with lot text input and new lines and totally no during typing in single line.
Duration of each lag i saw was lower then 100ms.
Your idea is to throttle height recalculation opperation with 1sec timeout.

So lets compare both your and current tactics:
Your tactic: 1000ms(best) 1000ms(worst)
Current tactic: 0ms(best) 100ms(worst)

As you see current tactic wins in all cases.

[edwh]

That doesn't match my experience, where I see visible delays during normal typing, where characters often don't appear for several seconds. The advantage of the periodic version is that the recalculation is batched rather than per-character, which might be more significant if there happens to be other CPU load on the machine. But it's your library :). Thanks for taking the time to test it and for making the code available.

…

On 6 December 2017 19:51:49 GMT+00:00, Snowshield ***@***.***> wrote: With CPU throttling 6x in **Chrome Dev Tools** i see only few lags with with lot text input and new lines and totally no during typing in single line. Duration of each lag i saw was lower then **100ms**. Your idea is to throttle height recalculation opperation with **1sec** timeout. So lets compare both your and current tactics: **Your tactic: 1000ms(best) 1000ms(worst) Current tactic: 0ms(best) 100ms(worst)** As you see current tactic wins in all cases. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #346 (comment)

[ghost]

Thats not my btw :)

[jlherren]

I also experience severe lag on some websites, when using Google Chrome. My analysis so far is as follows:

autosize recomputes the size of the textarea on every keypress and most of the time this calculated size will remain unchanged. However, autosize will always unconditionally hard-reset the height on the textarea, by setting it to the empty string and then setting it to the desired value, see this piece of code:

ta.style.height = '';
ta.style.height = (ta.scrollHeight+heightOffset)+'px';

This by itself does not cause any lag, but it does trigger a DOM change. The problem arises when a website or a browser plugin uses a MutationObserver to react to DOM changes and does expensive work based on these events. In my particular case it caused Passbolt's browser extension (a password manager) to rescan the entire DOM for username/password fields on every keypress. This can be a very slow operation on heavy pages (in my cases up to 30ms+ on each keypress).

I haven't tested any of this, but I figure one possible solution would be to get rid of the first line and just do:

ta.style.height = (ta.scrollHeight+heightOffset)+'px';

This wouldn't trigger the MutationObserver if the assigned value is identical to the already set value. However, if by any chance there is a good reason for first setting it to an empty string and then only setting the real value, then perhaps this might be better:

const newHeight = (ta.scrollHeight+heightOffset)+'px';
if (ta.style.height !== newHeight) {
    ta.style.height = '';
    ta.style.height = newHeight;
}

[jackmoore]

@jlherren You are correct that would be more efficient. The issue is that won't account for deletions (or cut, or paste of shorter content), so the textarea could only grow and never shrink. Which might be fine behavior for some applications, but I didn't want to explain that caveat. Removing the fixed height before measuring the scrollHeight addresses that.