Issue 112739 - loading autocorrect very slow
Summary: loading autocorrect very slow
Status: CLOSED IRREPRODUCIBLE
Alias: None
Product: Writer
Classification: Application
Component: configuration (show other issues)
Version: DEV300m83
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@sw
URL:
Keywords: regression
Depends on: 110722
Blocks: 114703 114704
  Show dependency tree
 
Reported: 2010-06-28 07:33 UTC by cno
Modified: 2010-09-27 15:07 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
userprofile autocorrect file (17.87 KB, text/xml)
2010-06-28 15:18 UTC, cno
no flags Details
replacement for the stock acor_nl-NL.dat to remove null-effect entry (3.32 KB, application/x-compressed)
2010-09-23 12:07 UTC, caolanm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description cno 2010-06-28 07:33:51 UTC
Start OOoDev300m83
Start new writer document
Type word and then space bar
  > it takes considerable time to execute that action

Start new writer document again
Type word and then space bar
  > now it goes as it should

Apparently loading autocorrect options takes long
Comment 1 cno 2010-06-28 07:34:59 UTC
see also 112623 ?
Comment 2 cno 2010-06-28 15:18:54 UTC
Created attachment 70264 [details]
userprofile autocorrect file
Comment 3 eric.savary 2010-09-03 23:08:43 UTC
Reassigned to SBA
Comment 4 cno 2010-09-04 08:24:07 UTC
adding sb as cc
Comment 5 cno 2010-09-05 11:10:25 UTC
Hi *,

I've done some measurements.

Reference:  
OOo321   < 1 sec

Dev builds:
300m83   appr. 10 secs
300m85   appr. 4 secs
330m1    appr. 4 secs
300m87   appr. 2,5 secs
330m6    appr. 2 secs

Conclusion
It has clearly improved over the last builds.
For me, 2 secs. is acceptable. But by no means, my computer my be considered
representative.
Comment 6 Stephan Bergmann 2010-09-09 12:44:08 UTC
Looked at this on Cor's machine during OOoCon.  Attaching gdb and repeatedly
stopping the process during the ~15 sec. it takes to open the dialog always
showed libfontconfig.so.1 on top of the stack, so I brought Cor into offline
contact with hdu to try and track this down.
Comment 7 cno 2010-09-22 22:19:19 UTC
Hi,
Luckily I had the right old dev-builds hanging around on my HD.
It turned out that the major decrease in preformance was introduced with m83.
In m82 al was fine...
(Same for all three issues: 
   issue 112623 (autotext), 
   issue 112739 (autocorrect)
   issue 114608 (mail merge),

Interestingly enough, the fix for the related issue 110078 was integrated in m83 ...
Comment 8 hdu@apache.org 2010-09-23 09:51:58 UTC
The observation in http://www.openoffice.org/issues/show_bug.cgi?id=112623#desc10 indicates that 
the patch in issue 110722 introduced this performance regression for locales such as nl or be.

@dtardon,@cmc: any idea how to prevent the fontconfig lookup from stalling the app for these languages? 
Maybe by just updating its config data somewhere? Or can we prevent it in our code (short of reverting the 
patch altogether)?
Comment 9 caolanm 2010-09-23 12:05:38 UTC
hmm, well I can reproduce this. But I think there's something else rather odd
going on. 

Try this, take the acor_nl-NL.dat and unpack it, in the DocumentList.xml there
is an entry that says that "eensgezinswoning" is to be auto-corrected as
"eensgezinswoning", i.e. its the same string. If I remove that entry and repack
it then the error goes away.

I'll attach a replacement here, does it make a difference if you use overwrite
your acor_nl-NL.dat with this one
Comment 10 caolanm 2010-09-23 12:07:00 UTC
Created attachment 71816 [details]
replacement for the stock acor_nl-NL.dat to remove null-effect entry
Comment 11 cno 2010-09-23 12:54:09 UTC
thanks
Indeed, both overwriting or correcting my own larger file solve the problem.
Comment 12 caolanm 2010-09-23 14:50:27 UTC
Some findings to date:

a) The replacement text being the same as the original word in the autocorrect
file makes writer spawn a slow full-document load to see if its a different type
of replacement via properties, we should remove that entry from the stock
autocorrect anyway as even without this bug it causes an extra delay. I'll do
that in issue 114704

b) For me what I see is that dtardon's change is good, but with it in place when
we look up the default CJK font we get a fontname back from fontconfig which
happens to be a CJK name, i.e. not in english one but we're not able to find the
fontname in our list of known fonts because our list is only of the English
names, so we keep looping searching for another one until 

c) In the fontconfig code we pick the best fit localized name for the fontname
to display. We should try in order of "Exact Language", "Close Language",
"English", "First Entry", rather than the current "Exact Language", "Close
Language", "First Entry", see issue 114703 for this

d) The font aliases are being read in truncated, see issue 114702

e) In e.g. Chinese locale only the English names of the font are being
displayed, I'm sure that the Chinese ones were displayed at some stage in the
past, hmm.
Comment 13 hdu@apache.org 2010-09-23 15:50:06 UTC
Great analysis, thanks!
With either the dictionary or issue 114703 and issue 114704 fixed the problem should be gone then...
The latter ones almost have stopper quality if they are so costly. Will have to test them individually to get a 
better picture of the risk vs. benefit ratio.
Comment 14 cno 2010-09-23 16:01:16 UTC
indeed thanks!

I asked on Dutch user list. 2 people responded and did not have my problems.
So it will be a problem for Dutch only (probably) and only part of the users
that run Linux. 
If fixing for 3.3.0 is to risky, we have a good workaround at hand.
Comment 15 caolanm 2010-09-23 16:59:30 UTC
re: "I'm sure that the Chinese ones were displayed at some stage in the past, hmm."

Ah, it sticks to what ever was the first name in the cache, so if it was first
seen under a non Chinese locale then it sticks to the English name forever, and
vice versa, nothing new there. 114703 + 114704 are probably the best fixes alright.
Comment 16 stefan.baltzer 2010-09-27 14:06:45 UTC
Since the problem is largely solved with the "Null replacement entry deletion"
that is adresses by issue 114704 for OOo 3.4, I set this one to "Worksforme".
Comment 17 cno 2010-09-27 15:05:40 UTC
and it is really fixed with issue 114703
Comment 18 cno 2010-09-27 15:07:32 UTC
and close