596507 - TSF: selecting large string in textbox causes slow down

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Makoto Kato [:m_kato]]

This is from Bug 496360 comment #40

(In reply to comment #39)
> But, when I select large text lines to copy it, CPU spikes 100%.  This root
> cause is xul!nsTextStore::GetText.  Since nsTextStore::GetText() always is
> called from MSCTF, it occurs another performance problem.

Absolutely, it's another bug. I guess that it's a pure performance problem of
nsContentEventHandler because nsTextStore::GetText() uses query event only
once.
# If the cause is that nsTextStore::GetText() is called many times a coping, we
should cache the result and we can fix it.


- Step
1. Turn on TSF by about:config
2. Browse test case that is attached on bug 496360.
3. select large line text such as 5,000 line

- Result
CPU spikes 100% and slow down.

Comment 1

[chado]

I'm also seeing new slowdown.
Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre ID:20100916041016
 Built from http://hg.mozilla.org/mozilla-central/rev/f38ef1080bfe

Select all (Ctrl+A):
 6 sec for  5,000 lines
27 sec for 10,000 lines (in a moment while TSF support disabled)

Cut selected text (Ctrl+X):
 3 sec for  5,000 lines
11 sec for 10,000 lines (in a moment while TSF support disabled)

Through testing above, I feel... with conditions:
1. while large text is in the textarea
2. before and/or after, when thee textarea has focus
3. focusing in thee textarea in the document, tab switching, 
   or app switching, e.g. opening new window (Ctrl+N)
takes more time with TSF support enabled.

using  2,000 lines or less, it's not so serious (on my machine.)
using  3,000 lines, Windows task manager starts showing spikes.
using 10,000 lines, they lock the browser for several seconds.

Comment 2

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

Hmm...

> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetSelection(ulIndex=4294967295, ulCount=1, pSelection=0xcae3a4, pcFetched=0xcae454)
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetSelection() succeeded
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetText(acpStart=0, acpEnd=-1, pchPlain=0x75169760, cchPlainReq=128, pcchPlainOut=0xcae034, prgRunInfo=0x75169860, ulRunInfoReq=33, pulRunInfoOut=0x751691f8, pacpNext=0x75169210), mComposition={ mStart=1515870810, mString.Length()=0, IsComposing()=false }
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetText() succeeded: pcchPlainOut=0xcae034, *prgRunInfo={ uCount=127, type=TS_RT_PLAIN }, *pulRunInfoOut=1964413432, *pacpNext=1964413456)
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetActiveView(pvcView=0xcae440)
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetActiveView() succeeded: *pvcView=1
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetTextExt(vcView=1, acpStart=0, acpEnd=610003, prc=0xcae47c, pfClipped=0xcae45c)
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetTextExt() succeeded: *prc={ left=572, top=428, right=1061, bottom=583 }, *pfClipped=true
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetActiveView(pvcView=0xcae440)
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetActiveView() succeeded: *pvcView=1
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetScreenExt(vcView=1, prc=0xcae48c)
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetScreenExt() succeeded: *prc={ left=571, top=426, right=1232, bottom=583 }
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetSelection(ulIndex=4294967295, ulCount=1, pSelection=0xcae470, pcFetched=0xcae570)
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetSelection() succeeded
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetText(acpStart=609907, acpEnd=-1, pchPlain=0x75169760, cchPlainReq=128, pcchPlainOut=0xcadf60, prgRunInfo=0x75169860, ulRunInfoReq=33, pulRunInfoOut=0x751691f8, pacpNext=0x75169210), mComposition={ mStart=1515870810, mString.Length()=0, IsComposing()=false }
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetText() succeeded: pcchPlainOut=0xcadf60, *prgRunInfo={ uCount=96, type=TS_RT_PLAIN }, *pulRunInfoOut=1964413432, *pacpNext=1964413456)
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetText(acpStart=609971, acpEnd=-1, pchPlain=0x75169760, cchPlainReq=128, pcchPlainOut=0xcae24c, prgRunInfo=0x75169860, ulRunInfoReq=33, pulRunInfoOut=0x751691f8, pacpNext=0x75169210), mComposition={ mStart=1515870810, mString.Length()=0, IsComposing()=false }
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetText() succeeded: pcchPlainOut=0xcae24c, *prgRunInfo={ uCount=32, type=TS_RT_PLAIN }, *pulRunInfoOut=1964413432, *pacpNext=1964413456)
> 0[2b0f140]: TSF: 0xa1fb3a0 nsTextStore::GetText(acpStart=609971, acpEnd=-1, pchPlain=0x75169760, cchPlainReq=128, pcchPlainOut=0xcadfa4, prgRunInfo=0x75169860, ulRunInfoReq=33, pulRunInfoOut=0x751691f8, pacpNext=0x75169210), mComposition={ mStart=1515870810, mString.Length()=0, IsComposing()=false }
> 0[2b0f140]: TSF: 0xa1fb3a0   nsTextStore::GetText() succeeded: pcchPlainOut=0xcadfa4, *prgRunInfo={ uCount=32, type=TS_RT_PLAIN }, *pulRunInfoOut=1964413432, *pacpNext=1964413456)


TSF asks, GetSelection(), GetText(), GetTextExt(), GetSelection() and GetText() * 3! Indeed these can cause slow. Each query creates flat text content of all content in editor since I did "Select All".

I think that ESM should store IMEContentObserver. And then, it should cache the flat text content until text change. Then, we can reduce the cost of such continuous similar request.

Comment 3

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

This is not related to bug 496360 (the cutting selected text performance might be improved by the patches if you cut text from not start of the text).

This should be fixed before enabling TSF on release build but I don't think that this is as serious as bug 496360.

Comment 4

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

Is this bug still reproduced? At least, on my environment, I cannot feel slow with the STR and even with large HTML editor (e.g., MDN).

I guess that bug 790516 already fixed (or hid) this bug. Bug 740516 makes that nsTextStore stores current text during a document lock. So, even if two or more times GetText() is called, nsContentEventHandler runs only once.

Comment 5

[Makoto Kato [:m_kato]]

I cannot reproduce this now.  This seems to be improved by some fixes.  We can close this by WORKSFORME or other reason.

Comment 6

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

Okay, thanks!

-> WFM