Created attachment 102677 [details] A Very Slow Chinese Document I tried writing some long documents using Chinese. However, as the number of characters approaches 1000, the scrolling becomes so slow that if I scroll once, I need to wait for several seconds for it to stop. I have created some simple comparason documents for Chinese and English. The English document is very fast though. I am under Funtoo Linux, amd64. The version I use is 4.2.5.2, but it also appeared for earlier versions. The attachments are the two simple documents I used for comparing.
Created attachment 102678 [details] A Very Fast English Document
Created attachment 102679 [details] A Very Slow Chinese Document
Confirmed with libreffice 4.3.0.2, ubuntu 14.04 x86. Scrolling and editing the Chinese document is very slow, compared with the english document. It may be because of the font fallback. Western font was applied to the Chinese chars. If you set a Chinese font (for example, SimSun, Wenquanyi MircoHei, etc) it will be fast again. Set to NEW, changed summary to reflect the font fallback issue.
I confirmed that if I set font explicitly, it becomes fast.
OSX 10.9.4 / LO 4.3.0.4, 4.4 master: The "slow" document seems sluggish to me whether or not the text is set explicitly to a Chinese font If anything it also seems rather slower on 4.4 master than in 4.3.0.4 release If I open the document and type some "a"s, it is initially slow but responsive as long as I keep typing. However, after stopping, the next letter typed is only processed after a long pause. I wondered based on this if spellchecking might be involved, but setting the language of the text to "None" doesn't seem to make any difference - unless there is some processing that isn't disabled when this is done
Poked at this a little with callgrind. There appear to be a number of villains in this case: 1) SwTxtFrm::CollectAutoCmplWrds Called from beneath SwLayIdle::DoIdleJob() Workaround: Disable Tools – Autocorrect Options... – Word Completion – Collect words 2) SwTxtFrm::_AutoSpell Called from beneath SwLayIdle::DoIdleJob() Workaround: Disable Tools – Automatic Spell Checking 3) SwTxtNode::CountWords Called from beneath SwLayIdle::DoIdleJob() Workaround: None found 4) SwTxtNode::CountWords Called from beneath DocumentStatisticsManager::IncrementalDocStatCalculate Workaround: None found Each of these spends a long time dissecting text using SwScanner. In addition, (3) and (4) appear to be counting the same words twice, which compounds the fact that it's a slow operation on a long paragraph. With all four disabled (commenting code out where necessary), editing the giant paragraph in the text document is merely slow rather than intolerable.
For a paragraph with N continuous characters of Chinese text (e.g. N x "中"), iterating over the paragraph with SwScanner will cause xdictionary::getWordBoundary() to be called N times, each of which will call xdictionary::seekSegment(), which will in turn iterate over each of the N characters -> N^2 operations This needs refactoring so seekSegment() doesn't keep doing the same work over and over again For Chinese text, the path through from SwScanner to xdictionary goes like this: frame #1: 0x0000000110919243 libi18npoollo.dylib`com::sun::star::i18n::xdictionary::seekSegment(this=0x000000010c08a000, rText=0x00007fff5fbfa930, pos=1, segBoundary=0x000000010c08a028) + 115 at xdictionary.cxx:280 frame #2: 0x00000001109199dd libi18npoollo.dylib`com::sun::star::i18n::xdictionary::getWordBoundary(this=0x000000010c08a000, rText=0x00007fff5fbfa930, anyPos=1, wordType=3, bDirection=true) + 173 at xdictionary.cxx:412 frame #3: 0x00000001109073e7 libi18npoollo.dylib`com::sun::star::i18n::BreakIterator_CJK::getWordBoundary(this=0x000000011ff93ab8, text=0x00007fff5fbfa930, anyPos=1, nLocale=0x00000001206d7600, wordType=3, bDirection='\x01') + 119 at breakiterator_cjk.cxx:81 frame #4: 0x000000011090753c libi18npoollo.dylib`non-virtual thunk to com::sun::star::i18n::BreakIterator_CJK::getWordBoundary(this=0x000000011ff93ae0, text=0x00007fff5fbfa930, anyPos=1, nLocale=0x00000001206d7600, wordType=3, bDirection='\x01') + 92 at breakiterator_cjk.cxx:88 frame #5: 0x000000011090e0e4 libi18npoollo.dylib`com::sun::star::i18n::BreakIteratorImpl::getWordBoundary(this=0x0000000117072b78, Text=0x00007fff5fbfa930, nPos=1, rLocale=0x00000001206d7600, rWordType=3, bDirection='\x01') + 612 at breakiteratorImpl.cxx:182 frame #6: 0x000000011090e1dc libi18npoollo.dylib`non-virtual thunk to com::sun::star::i18n::BreakIteratorImpl::getWordBoundary(this=0x0000000117072ba0, Text=0x00007fff5fbfa930, nPos=1, rLocale=0x00000001206d7600, rWordType=3, bDirection='\x01') + 92 at breakiteratorImpl.cxx:186 frame #7: 0x00000001184e85d0 libswlo.dylib`SwScanner::NextWord(this=0x00007fff5fbfa918) + 1296 at txtedt.cxx:836
Matthew J. Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a34a8fca21c670c4e7ee147d05ed9e6e4136cbe1 fdo#81272 Speed up break iterators The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=997d1387abcfa40eca8d15a2fe025edc4a1de040 Revert "fdo#81272 Speed up break iterators" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Matthew J. Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=44ead04eb5fc61a3f56f783adb1509fab440e212 fdo#81272 Speed up break iterators The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
caolanm->fdbugs: Can we call this fixed now ?
Two concerns with closing at this point: 1) The reporter had a slightly different symptom to the problem that's just been patched - that the slowdown was dependent on fonts. I never reproduced that on OSX; the reported issue may not be identical. 2) After the patch, performance with CJK text is much better in the 10,000 character range, but still poor with a few times that (30k or above is still appreciably slow on my local machine). This compares poorly with a paragraph of the same number of western text characters. I have a few ideas on possibilities for further improving performance, but not much that's as simple as the first patch...
(In reply to Matthew Francis from comment #12) I confirm that this bug still exists in the following version: Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: zh_CN Fedora 22 X64. Steps to reproduce: 1. Open attachment 102679 [details] with Writer; 2. Try to delete some chars using the BACKSPACE, or try to type in some text. --> Very slow.
(In reply to Matthew Francis from comment #12) I confirm that I am affected by this bug too, in this version and following the same steps as Kevin Suo: Version: 4.4.7.2 Build ID: 4.4.7.2-1.fc22 Locale: en_US.UTF-8 Fedora 22 x64
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Still reproducible with Version: 6.2.0.0.alpha1+ Build ID: 740b99783b5480fcd1e5fce7c1beb5967d015041 CPU threads: 4; OS: Mac OS X 10.14.1; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); Calc: threaded Just deleting characters from the text document on MacOS Mojave using the backspace key is terribly slow.
Created attachment 157238 [details] perf flamegraph svg
I don't see the problem in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a9cc066a86c6bd3423c5802c5a4eded55a50c754 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded Alex, Kevin, could you please retest it on your machines?
I retested the attachment "A Very Slow Chinese Document" in Version: 7.3.0.3 / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 8; OS: Mac OS X 12.2.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_NL.UTF-8); UI: en-US Calc: threaded on a Mac mini (M1, 2020), 16GB of RAM, on macOS 12.2.1 - Deleting, adding, scrolling and searching for characters is as fast as can be expected - If I search for "字" and enable "Find All", it takes roughly 3 seconds for the results to appear.
WORKSFORME in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 02e1be8883a08ab17f3e890a834ab88f13c5867d CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN Calc: threaded Close as RESOLVED WORKSFORME.
Sorry for the late reply, but I am definitively still seeing this bug. To reproduce: 1. Tools -> Options -> LibreOffice Writer -> Basic Fonts (Asian) Set the Default (top row) to a Western font, for example Liberation Serif or DejaVu Sans. (Alternatively, set it to an Asian font, close LibreOffice and uninstall that Asian font from your computer.) 2. Open attachment 102679 [details] with Writer; 3. In the middle of the first page, try to delete some chars using the BACKSPACE, or try to type in some text. Slow to Very slow. 4. Search for "字" and enable "Find All". Very slow, even unresponsive for a while. To show that the (fallback) font is the problem: 5.a. Change the font of the text to an Asian font, for example Noto Sans CJK SC or AR PL UKai TW. or: 5.b. Tools -> Options -> LibreOffice Writer -> Basic Fonts (Asian) Set the Default (top row) to an Asian font, for example Noto Sans CJK SC or AR PL UKai TW. Now steps 3 and 4 become normal speed (fast) again. Version: 7.4.1.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 2; OS: Linux 5.10; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 1:7.4.1-1~bpo11+2 Calc: threaded