Open
Bug 1398572
Opened 7 years ago
Updated 2 years ago
Setting input.value is rather string-usage heavy
Categories
(Core :: DOM: Editor, enhancement, P3)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: smaug, Unassigned)
References
(Blocks 1 open bug)
Details
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•7 years ago
|
||
I tried to do that in nsTextEditorState::SetValue() like:
nsAString* currentValue = aOldValue;
nsAutoString currentValueBuf;
if (!aOldValue) {
mBoundFrame->GetText(currentValueBuf);
currentValue = ¤tValueBuf;
}
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.
|
||
Updated•7 years ago
|
Priority: -- → P3
|
Reporter | |
Comment 2•6 years ago
|
||
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•5 years ago
|
||
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.
Depends on: 1588745
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•