Issue 112623 - loading autotext very slow
Summary: loading autotext very slow
Alias: None
Product: Writer
Classification: Application
Component: configuration (show other issues)
Version: DEV300m83
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@sw
Keywords: regression
Depends on: 110722
  Show dependency tree
Reported: 2010-06-23 10:30 UTC by cno
Modified: 2011-02-11 17:00 UTC (History)
5 users (show)

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

userprofile autotext file (567 bytes, text/xml)
2010-06-28 15:20 UTC, cno
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description cno 2010-06-23 10:30:30 UTC
- Open writer document
- Toolbar Insert
- Click autotext icon, or do it by keyboard
 > takes seconds before menu is shown

Note: I have copied a .bau file from an older installation to the user path. 
Do this freqently however, and never foud a problem with it.
Comment 1 cno 2010-06-28 15:20:41 UTC
Created attachment 70265 [details]
userprofile autotext file
Comment 2 eric.savary 2010-09-03 23:08:15 UTC
Reassigned to SBA
Comment 3 cno 2010-09-04 08:23:20 UTC
sb has some data from my system about (loading) libs involved
(picked during the OOocon Openings ceremony ;-) )
Comment 4 Stephan Bergmann 2010-09-09 12:44:53 UTC
Just to clarify, what Cor and I looked at was issue 112739 (see there).
Comment 5 cno 2010-09-21 11:31:38 UTC
The output retrieved was
Program received signal SIGINT, Interrupt.
0xb38f430f in ?? () from /usr/lib/
(gdb) where
#0 0xb38f430f in ?? () from /usr/lib/
#1 0xb38f4b65 in FcLangSetHasLang () from /usr/lib/
#2 0xb38f6db4 in ?? () from /usr/lib/
#3 0xb38f6f49 in ?? () from /usr/lib/
#4 0xb38f71b7 in ?? () from /usr/lib/
#5 0xb38f7a0c in ?? () from /usr/lib/
#6 0xb38f7f77 in FcFontSetMatch () from /usr/lib/
#7 0xb632a562 in ?? ()
from /home/cono/OOo330m5/ooo-dev3/program/../basis-link/program/
#8 0xb632a060 in psp::PrintFontManager::Substitute(rtl::OUString const&,
rtl::OUString&, rtl::OString const&, psp::italic::type&,
psp::weight::type&, psp::width::type&, psp::pitch::type&) const ()
from /home/cono/OOo330m5/ooo-dev3/program/../basis-link/program/
#9 0xb3b0c326 in ?? ()
from /home/cono/OOo330m5/ooo-dev/basis3.3/program/
#10 0xb3b0c607 in ?? ()
from /home/cono/OOo330m5/ooo-dev/basis3.3/program/
#11 0xb611b4b3 in ImplDevFontList::ImplFindByFont(ImplFontSelectData&,
bool, ImplDirectFontSubstitution*) const ()
from /home/cono/OOo330m5/ooo-dev3/program/../basis-link/program/
#12 0xb611c2ac in ?? ()
from /home/cono/OOo330m5/ooo-dev3/program/../basis-link/program/
#13 0xb611c8bb in ?? ()
---Type <return> to continue, or q <return> to quit--- 

I've done suggestions as update fontconfig cache,  check user rights on the
various locations, ..

Alas, that does not make any difference for me, who is working with a default
Ubuntu 10.04.

Relation with issue 110078 is suggested, but that was already fixed long time ago..

So ... I 'll ask some help from Linux OS-cracks with checking fontconfig stuff.

(In the mean time, I run in a next performance issue: 114608 )
Comment 6 cno 2010-09-22 22:19:24 UTC
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 ...
So I add some people as cc on this issue ;-)
Comment 7 cno 2010-09-23 06:57:37 UTC
I did have some contact with Gary(1) - who could not reproduce  - but he asked
me about some libconfig stuf from my machine, to check with his. It appeared to
be the same (which does not surprise me, cause I run a regularly updating Ubuntu
I paste it here - if it may be of any help ..

>> cono@cono-tm-new:~$ ls -al /usr/lib/
>> lrwxrwxrwx 1 root root 22 2010-05-15 23:35 /usr/lib/
>> ->
>> cono@cono-tm-new:~$ ls -al /usr/lib/
>> -rw-r--r-- 1 root root 191132 2010-01-20 16:38
>> /usr/lib/
>> cono@cono-tm-new:~$ apt-cache policy libfontconfig1
>> libfontconfig1:
>>     Geïnstalleerd: 2.8.0-2ubuntu1
>>     Kandidaat: 2.8.0-2ubuntu1
>>     Versietabel:
>>    *** 2.8.0-2ubuntu1 0
>>           500 lucid/main Packages
>>           100 /var/lib/dpkg/status

Comment 8 2010-09-23 08:00:29 UTC
That is a very interesting observation, thanks! From the changes that got into m83 the most probable 
candidates IMHO are the CWSses tl80 or vcl111.

If it was vcl111 then the task then the problem was probably introduced by seemingly innocent patch 
from issue 110722.
@cornouws: To check this idea could you please retest when logged into a different locales, e.g. "en"?
Comment 9 cno 2010-09-23 08:50:48 UTC
Thanks for your attention :-)

I've set the locale in Tools|Options|Language settings|Language.
If that is what you mean:
Setting locale Eng(US) or Eng(UK) has as result :
 - autocorrect starts immediately
   whereas with Dutch(Netherlands) it takes appr. 3 secs.
 - opening Autotext Window (Ctrl-F3) still is the same: bad

Changing locale to Dutch(Belgium) has the same effect.
Comment 10 cno 2010-09-23 08:52:52 UTC
I forgot to check effect on MailMerge
There is no effect on that when changing the locale
Comment 11 2010-09-23 10:19:09 UTC
Interesting, I updated issue 112739 regarding your findings on AutoCorrect.
Now for the other two cases please set the environment variable SAL_DISABLE_FC_SUBST with e.g.
before starting soffice in that environment and retest the AutoText and MailMerge cases.
Comment 12 cno 2010-09-23 11:57:11 UTC
bingo - this solves *all three* problems :-)
Comment 13 cno 2010-09-27 15:06:08 UTC
This is fixed with issue 114703
Comment 14 cno 2010-09-27 15:07:02 UTC
and close
Comment 15 cno 2010-09-27 15:07:58 UTC
and close
Comment 16 cno 2010-11-24 14:23:33 UTC
Bad news, there is something weird going on with the 330m16 (rc6)

When I use it with my 3.2.1 user profile: 
 - (I) first start of autocorrect and 
 - (II) loading of autotext are really slow (even much worse then in the time I
reported this bug).
And after closing the autotext window, 
 - (III) it takes 15 seconds or so before I can put the focus back in the document.

What does not help:
- Setting locale to English (see previous Autotext first
start then needs still 1 minute or so.
- Changing the acor_nlNL.dat (see does not make a
- When I turn off the Dutch spell check extension (1.1.1 / 2.0.0) (just a try).

What does help (for I, II and III) :
- Starting with export SAL_DISABLE_FC_SUBST=1
- Starting with a fresh user profile

The same problems appear when I install
Also rc5 shows the same problem (usually I run RC and DEV builds with clean user
profiles. Therefore I did not see this issue earlier - sorry).

[ General note: apart from these specific problems, loading autotext takes about
2-3 seconds (also in DEV300m93), which is considerably longer then the 0.5 sec
in 3.2.1. ]
Comment 17 cno 2010-11-24 14:31:54 UTC
note (maybe hint to cmc?): when I start LibO beta 3 with my OOo 321 user
profile, the problems doe not show up.
Comment 18 cno 2010-11-24 22:37:09 UTC
so the obvious two routes are:
a. start with new user profile and start piece by piece importing the stuff from
my 321 profile
b. start with the 321 profile and removing step by step.

I tend to the second one. Any suggestions appreciated :-)
Comment 19 cno 2010-11-29 21:50:31 UTC
hi all,

There is a long list of stuff that does not have influence when I remove it or such.

Now I stumbled over the file 

When I remove that, and start OOo again, it starts asking if I want to register
- which I thought was in a different file. but OK.

It immediately produces for me 318.9 KB
When I start typing (and wait a minute or so till autocorrect is ready) then the
file is a little larger.

I compared both files and am happy to send it via mail. Maybe someone can read
from that hwat is going wrong?

Thanks - Cor
Comment 20 cno 2011-02-09 12:03:33 UTC
As this seems to be a me-only problem (wah :-( )
and I preferred the route of step by step import / fresh setting options over
importing the old muk, cause testing is far more time consuming, I would not
object if the devs/qa people choose to let this issue as is, and resolve as wontfix.
Comment 21 Mathias_Bauer 2011-02-11 15:09:20 UTC
Cor, this is a dangerous offer. I'm tempted to agree. :-)
Comment 22 stefan.baltzer 2011-02-11 16:17:00 UTC
Me too :-)
Set to "Wontfix".
Comment 23 stefan.baltzer 2011-02-11 16:18:16 UTC
Closing this one.
Comment 24 cno 2011-02-11 17:00:50 UTC
Well, basically I thought about asking you if you'd maybe like to think over
this during the weekend. But it's fine for me now too ;-)