Issue 101726 - Speed up autocorrect replacement table loading time
Summary: Speed up autocorrect replacement table loading time
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO310m11
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: performance
Depends on:
Reported: 2009-05-10 14:16 UTC by tommy27
Modified: 2017-05-20 10:47 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description tommy27 2009-05-10 14:16:05 UTC
Speed up autocorrect replacement table loading time 

after adding more and more autocorrect entries i have noticed progressive 
increase of the time needed to load the autocorrect replacement table from the 
Tools menu.

Actually with a database of 36000 entries in my acor.dat file i need 4 minutes 
to have the replacement table opened (my system is Win Vista 64 but, centrino 
2, 4GB RAM... i have the same results on XP 32bit Pentium4 521BM RAM). 

In that time OOo gets stuck and no other operation is possible.
I suggest to find a way to make loading time faster and independent from the 
number of entries in the database.

as i said the more issue you have the slower is the table to load.
when you reach higher numbers of entries like 64000 you need even 15 minutes to 
load the table.
Comment 1 tommy27 2009-12-05 10:32:21 UTC
added "performance" keyword.
I hope people from the OOo Performance team will take care of this issue.

the very slow loading of the autocorrect replacement table is also preventing 
users to quicly enter the other tabs that make part of OOo dialog window (i.e. 
autocomplete, exceptions, etc. etc.)
Comment 2 Olaf Felka 2009-12-07 06:45:37 UTC
@ tl: something for you?
Comment 3 tommy27 2009-12-07 07:28:37 UTC
related informations can be found in these issues:
Summary: autocorrect limit. acor.dat with entry 65535: Loop and/or loss of acor 

there's dependancy betwwen the number of stored enties and loading times.
once you get closer to the 65535 entries limit, replacement table loading time 
becomes very very slow (almost 15 minutes on my laptop).

Summary: Enter custom autocorrect entries without opening the replacement table.

this a feature request. i suggest adding a text field below OOo right click 
menu correct words suggestion, in order to assign a custom autocorrect item 
without opening the slow loading replacemente table.


Summary: common autocorrect replacement table for certain languages subgroups 
(i.e. en-US, en-GB)

creating non-localized versions of autocorrect replacement tables for some 
languages would temporarily workaroud the above issues since another 65535 
entries could be available and being a brand new autocorrect database this 
would be initially very fast to load


hope this may help understand the problems about OOo autocorrect feature.

thanks for your interest.

Comment 4 thomas.lange 2009-12-07 08:51:57 UTC
tl->os: Please take over. Thanks!
Comment 5 Oliver Specht 2009-12-07 09:02:00 UTC
target, platform, OS set

Loading 64K entries into a ListBox is not only slow but it is also hard to
handle. On the other hand you seem to be the only one who uses AutoCorrection
with such a number of replacements. 
Comment 6 tommy27 2009-12-08 08:17:48 UTC

First of all let me thank you for interest and time spent on this topic.

I have some thoughts to share.

1- speeding up the loading of that list with so many entries is probably not an 
easy match.
I understand this. And it's up to you to see if this is technically feasible...
If it's not I suggest to cosndierer Issue 101714... this new feature would 
prevent loading the slow table and add new autocorrect entries in few seconds, 
saving time and produictivity.

2- the slow loading time issue is also present with non saturated acor.dat 
as I told in previous posts, with a virgin .dat file the table loads in less 
than a second then its performance progressively declines...

5 seconds with 4K entries...
4 minutes with 36K entries...
10-15 with >50K entries

apart from my case (65K) which may not be a common situation, you still have 
long loading times even for smaller databases like 36K. The time your OOo gets 
stuck to load the table hurts productivity.

I had to disable the Ctrl+H hotkeys since I experienced accidental hits that 
meant OOo freeze and wait or Ctrl+Alt+Canc. 

Maybe something may be done for speeding the table in earlier phases of filling 
(i.e. 36K example).

3- sooner or later other users will accumulate high numbers of autocorrect 
I understand I'm a particular case but my job consists of writing medical 
reports all the day, so the more I write, the faster I type, the higher numbers 
of errors I do which I send to autocorrect to avoid future mistakes.

However I took 2 years to fill the first acor.dat file... I started using OOo 
in march 2006 and reached the 65K limit in march 2008 when I reported the 
then from april 2008 to december 2009 I added other 53234 entries in another 
acor.dat file (do you remember my workaround using the italian acor.dat file 
and the global acor.dat file).

So, I expect that even if other users do a less intensive use of that feature, 
with time they will reach my point... there's people who's using OOo from 
earlier versions and is accumulating entries overs entries will certainly 
experience progressive slowness of the replacement table (= reduced 
performance) and 65K limit crash and autocorrect database implosion (= loss of 

4- thanks again for your attention.   
according to my estimates I still have 5-6 months left to reach again the 65K 
limit or to learn to type without errors....  :-)

Comment 7 tommy27 2010-07-28 12:58:44 UTC
besides being slow to open, autocorrect replacement table seems to have some 
troubles on Windows Vista 64bit with big databases.

using the same versione of OOo (X-OpenOffice 3.2.1 from http:// ) with the same User profile, 
the table fails to load on Vista 64bit leaving the document freezed (Ctrl+Alt
+Canc needed to start working again).

the same user profile and OOo version have no troubles at all loading the same 
repalcement table on Windows XP 32 bit on a less performing PC (the Vista 64bit 
one has  centrino 2 CPU and 4GB of RAM)

Comment 8 tommy27 2010-12-12 22:44:06 UTC
well, it seems that the issues I reported with Vista on my previous post are 

sometimes the replacement table opens up, other times it doesn't...
however I can't figure out what makes it work or fail on either situations...

in XP the replacement table always opens up, it requires a lot of time with 
larger databases but I have never experienced those troubles I had sometimes with 
Comment 9 tommy27 2012-05-03 18:51:39 UTC
this bug has been fixed in LibreOffice 3.5.1
Comment 10 Marcus 2017-05-20 10:47:39 UTC
Reset assigne to the default "".