1398572 - Setting input.value is rather string-usage heavy

Status: NEW

(Core :: DOM: Editor, enhancement, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

When setting input.value we seem to copy string to local nsAutoStrings and what not. That is showing up badly in the profiles.
Maybe we could try to avoid that, at least in common cases.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sick)]

I tried to do that in nsTextEditorState::SetValue() like:

nsAString* currentValue = aOldValue;
nsAutoString currentValueBuf;
if (!aOldValue) {
  mBoundFrame->GetText(currentValueBuf);
  currentValue = &currentValueBuf;
}

However, it was slower than without this kind of hack with VC. I guess that VC optimizes something even with current code but my experimental patch killed the optimization.

So, be careful about the result.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

This is still showing up in the profiles. I couldn't immediately see how to improve the situation, but I would expect that we should be able to reuse heap allocated strings usually.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sick)]

After fixing bug 1588745, TextControlState (previously called nsTextEditorState) uses nsString for new value (setting value). I think that we should create comparing method with current value instead of getting (copying) current value for the comparison.