Apache OpenOffice (AOO) Bugzilla – Issue 101726
Speed up autocorrect replacement table loading time
Last modified: 2017-05-20 10:47:39 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.
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.)
@ tl: something for you?
RELATED ISSUES related informations can be found in these issues: http://www.openoffice.org/issues/show_bug.cgi?id=87672 Summary: autocorrect limit. acor.dat with entry 65535: Loop and/or loss of acor data 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). --------------------- http://www.openoffice.org/issues/show_bug.cgi?id=101714 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. --------------------- http://www.openoffice.org/issues/show_bug.cgi?id=101224 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. tommy27
tl->os: Please take over. Thanks!
target, platform, OS set ->tommy27: 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.
@os 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 files... 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 entries. 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 issue... 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 data) 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.... :-)
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:// www.winpenpack.com/main/download.php?view.1035 ) 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)
well, it seems that the issues I reported with Vista on my previous post are inconstant... 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 Vista.
this bug has been fixed in LibreOffice 3.5.1
Reset assigne to the default "issues@openoffice.apache.org".