Apache OpenOffice (AOO) Bugzilla – Issue 83554
performance: svx::HangulHanjaConversion is way too expensive
Last modified: 2013-08-07 14:44:35 UTC
Issue 83491 complains about massive performance regressions even though the CWS that introduced it made text layout only a little bit more costly. Analyzing the situation showed that the whole textbox is reformatted from top to bottom for every single replaced codepoint! This causes quite some sluggishness. It would be better to convert whole paragraphs or even the whole document at once and reformat then. Here is the backtrace of the performance problem, which may be helpful to find the culprit of the excessive reformats: #0 OutputDevice::GetTextArray (this=0xaed451d8, rStr=@0xaace00c0, pDXAry=0xabed71ec, nIndex=0, nLen=4) #1 0xb1c4bf43 in SvxFont::QuickGetTextSize (this=0xbfc69128, pOut=0xaed451d8, rTxt=@0xaace00c0, nIdx=0, nLen=4, pDXArray=0xabed71ec) at unxlngi6.pro/inc/tools/gen.hxx:250 #2 0xb1cbe316 in ImpEditEngine::CreateLines (this=0xaad56d94, nPara=0, nStartPosY=0) at ./ impedit.hxx:932 #3 0xb1cbf89e in ImpEditEngine::FormatDoc (this=0xaad56d94) at ./editdoc.hxx:593 #4 0xb1cc280a in ImpEditEngine::FormatAndUpdate (this=0xaad56d94, pCurView=0xaab8e36c) at svx/source/editeng/impedit3.cxx:3948 #5 0xb1c99492 in EditView::SetAttribs (this=0xaab8e36c, rSet=@0xaf2a7490) at svx/source/editeng/ editview.cxx:612 #6 0xb1ccedec in TextConvWrapper::ChangeText_impl (this=0xbfc6963c, rNewText=@0xbfc69344, bKeepAttributes=1 '\001') at svx/source/editeng/textconv.cxx:624 #7 0xb1ccefaf in TextConvWrapper::ChangeText (this=0xbfc6963c, rNewText=@0xbfc693b8, rOrigText=@0xabd75450, pOffsets=0x1, pESelection=0xbfc693a8) at svx/source/editeng/ textconv.cxx:567 #8 0xb1ccf29a in TextConvWrapper::ReplaceUnit (this=0xbfc6963c, nUnitStart=0, nUnitEnd=-1077505096, rOrigText=@0xabd75450, rReplaceWith=@0xaacd68fc, rOffsets=@0xbfc6945c, eAction=svx::HangulHanjaConversion::eExchange, pNewUnitLanguage=0xbfc6945a) at svx/source/editeng/textconv.cxx:446 #9 0xb1d0cb4a in svx::HangulHanjaConversion_Impl::implChange (this=0xabd753f0, _rChangeInto=@0xaacd68fc) at svx/source/dialog/hangulhanja.cxx:916 #10 0xb1d0cdb5 in svx::HangulHanjaConversion_Impl::ContinueConversion (this=0xabd753f0, _bRepeatCurrentUnit=false) at unxlngi6.pro/inc/stl/stl/_tree.h:172 #11 0xb1d0d263 in svx::HangulHanjaConversion_Impl::DoDocumentConversion (this=0xabd753f0) at svx/source/dialog/hangulhanja.cxx:815 #12 0xb1d0d283 in svx::HangulHanjaConversion::ConvertDocument (this=0xaf2a7490) at unxlngi6.pro/inc/stl/stl/_auto_ptr.h:63 #13 0xb1ccf401 in TextConvWrapper::Convert (this=0xbfc6963c) at svx/source/editeng/textconv.cxx: 637 #14 0xb1cc6d06 in ImpEditEngine::Convert (this=0xaad56d94, pEditView=0xaab8e36c, nSrcLang=1028, nDestLang=2052, pDestFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0', bMultipleDoc=1 '\001') at svx/source/editeng/impedit4.cxx:1651 #15 0xb1c9a68c in EditView::StartTextConversion (this=0xaed4529c, nSrcLang=1028, nDestLang=0, pDestFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0', bMultipleDoc=1 '\001') at svx/source/editeng/editview.cxx:1062 #16 0xb1ce16e4 in OutlinerView::StartTextConversion (this=0xaf2a7490, nSrcLang=1028, nDestLang=21148, pDestFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0', bMultipleDoc=1 '\001') at svx/source/outliner/outlvw.cxx:1375 #17 0xae1b41bd in sd::Outliner::StartConversion (this=0xabd81800, nSourceLanguage=1028, nTargetLanguage=2052, pTargetFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0') at sd/source/ui/view/Outliner.cxx:1658 #18 0xae3b47c0 in sd::FuHangulHanjaConversion::StartConversion (this=0xabeca48c, nSourceLanguage=1028, nTargetLanguage=2052, pTargetFont=0xbfc69888, nOptions=1, bIsInteractive=0 '\0') at sd/source/ui/func/fuhhconv.cxx:185 #19 0xae3b5368 in sd::FuHangulHanjaConversion::StartChineseConversion (this=0xabeca48c) at sd/ source/ui/func/fuhhconv.cxx:305
reassigning
.
TL: According to HDU the performance problem splits like this: - ~30% due to painting - ~65% due to formatting According to AF the formatting problem can not be fixed in a reasonable time frame. It is likely to require a complete new implementation of the interaction between sd and EditEngine/Outliner. Changing target to OOo later.
@TL: on a second thought the problem SSA describes in issue 83491 was caused by this issue, even though even though the CPU load caused by it only 30% of the problem workload: In the test scenario there was an X11 server without XRENDER extension involved and repainting antialiased text in this context is limited by the round trip latencies from/to the X11 server. The resulting timeout of the testtool on this test is a result of the cumulative latencies. It would be great if repaints could be reduced or even be completely avoided while doing the text conversion.
Correction to my comment above:"the problem SBA describes" instead of "the problem SSA describes" As agreed with TL the target milestone needs to be adjusted because the scenario mentioned above (X11 without XRENDER) is still too important. TL: feel free to adjust the target again if necessary
No more issues accepted for OOo 2.4 unless there are serious problems.
Missed 3.0 code freeze, no showstopper -> 3.1
As discussed with SBA setting target to OOo 3.2 since this one is not that easy to fix and test with its potential implications. And thus making a quick fix for 3.1 should be avoided.
No showstopper, setting target to 3.4