https://bugs.freedesktop.org/show_bug.cgi?id=49350
--- Comment #33 from Tomaz Vajngerl <qui...@gmail.com> 2012-09-22 19:51:51 UTC --- (In reply to comment #31) > from tests I've done on master LibO 3.7.x with your fix, it seems that the > "click OK" delay lenght depends upon 2 factors: > > 1- size of the autocorrect database > 2- alphabetical position of the newly added entry > > which means that it takes longer to save new entries in larger databases, and > it takes longer to save a "Z" entry rather than an "A" entry. > > adding a "A" entry to the replacement table takes: > - 8 seconds in a 55K acor.dat file > - 22 seconds in a 119K acor.dat file > > adding a "Z" entry instead takes: > - 1 minute and 40 seconds in a 55K acor.dat file > - 6 minutes and 10 seconds in a 119K acor.dat file > > tests were performed on Windows Vista 64bit, Intel Centrino 2, 2.27 GHz, 4GB > RAM). Ouch.. this is crazy. > so it seems to me that most of the time is used/wasted resorting in > alphabetical order the whole autocorrect database. > > on the other hand adding a new autocorrect entry from "mouse right click > suggestions" is extremely fast (1 or 2 seconds; maybe slightly slower when > adding to a 119K database rather than a 55K database). > > I have a theory about this different behaviour between "mouse" and > "replacement > table" autocorrect methods but I need to do another test to confirm it or > not.... stey tuned... more to come... No.. the actual problem is (or was) that the dialog makes its own copy of all entries and afterwards it tries to synchronize its own copy with the main structure (where the entries are stored and checked when you type) in a very non-efficient way. The behavior you saw was probably the side-effect of the synchronization. For 'z' entries the algorithm needed to go through the whole list to find a match - but for 'a' entries only some entries at the beginning. I have changed this so I only store what has been deleted and added to the list and now there is no need for synchronization at all. Using this approach it takes about 12 sec. when I change some entries (at the beginning or end). It generally works but I have to test all scenarios and make some more improvements to the code before I commit - so it may take some time. It still takes too long to save to a file and I think that I know the reason. I think that every time a new entry is added, the acor file is written. Which then means that when you add 10 entries, acor file is (re)written 10 times. I am not yet sure about this but maybe you can test this. > did you see my upload? Yes thanks! > Tomaz, regarding your fix, did you actually touch the areas that Micheal Meeks > said could be responsible for a 10x speedup (see Comment 25 ) or did you tweak > another part of the code? Yes - the first fix was based on information on this page. I tweaked the usage of SetFont method in PaintEntry1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
