Created attachment 60864 [details] large autocorrect database when you enter the autocorrect replacement table adding new entries, you have to click “OK” to save them when you are done. If the autocorrect database is very large, it takes several seconds to close the replacement table and save the new entries steps to reproduce 1- download the attached acor_it-IT.dat file (more than 47500 entries) 2- put it into the autocorrect folder which is: /home/<user>/.libreoffice/3/user/autocorr (Linux) or \Users\<user>\AppData\Roaming\LibreOffice\3\user\autocorr (Windows) 3- open a Writer new sheet 4- Format -> Autocorrect -> Autocorrect options -> Replace 5- select Italian (Italy) 6- add one random autocorrect entry and click New 7- click OK LibO freezes for several seconds before closing the replacement table. When the autocorrect database is small it's almost instantaneous, but when you have a large database (like in this scenario) things become very slow. -------------------- it seems that OOo/LibO autocorrect feature has many performance issues when dealing with large autocorrect databases. loading the replacement table was incredibly slow in OOo ( https://issues.apache.org/ooo/show_bug.cgi?id=101726 ) with almost 15 minutes needed in OOo 3.3 to load a 65000 entries list.... now thanks to Deszi Szabolcs patch in LibO 3.5.1 this huge time has been reduced to a few seconds. (great improvement indeed!!!) http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-1&id=14f0c12942a8557d3d9dcdaea2e80bad34f40d86 large autocorrect databases also cause some freezing while start typing ( Bug 46805 ) which has been partially solved by Michael Meeks with his 3.5.4 patch that reduced to 50% the freeze time. http://cgit.freedesktop.org/libreoffice/core/commit/?id=a617eecdb6b2f8d6bb1b20674f8be8ce4d60f2d1&g=libreoffice-3-5 however, saving into the replacement table is still very slow in LibO despite the previous bug fixes. adding and saving new autocorrect entries is instead very fast if you use "right click autocorrect" suggestions. so the slowness seems related to the closure of the replacement table itself.
just to add that this issue has been reproduced on different Windows O/S (XP 32bit, Vista 64bit, 7 64bit). is there any Linux user that can test it as well?
More or less REPRODUCIBLE with LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80), German langpack installed, Italian spelling module installed (if this is of any importance), on MacOS X 10.6.8 with German UI. I see the spinning curser for some seconds * after step 7, as reported by tommy27 * after step 6 (when the new entry is added to the autocorrection table) * when I repeat steps 4 to 7 immediately after step 7: when I open the 'Autocorrect options' dialog window a 2nd time, the selection 'Italian (Italy)' is already pre-selected (good!) and the large autocorrection table is loaded immediately, this takes some time. Of course, on my machine I would not call any of these delays a 'freeze' -- they take between 1 and 3 seconds for me. But this may be related to the fact that my machine is not that slow ;-) and has plenty of RAM installed and a SSD (solid-state drive), therefore if there are any disc-access operations involved they will get handled rather fast. On older machines these delays may take much more time and will be really annoying, I suppose. Personally I don't think this is a 'most annoying bug' (no regression, no crash, no data loss, no misleading error message, etc.), but I agree it would be very nice if there was some speedup possible.
(In reply to comment #0) > 2- put it into the autocorrect folder which is: > /home/<user>/.libreoffice/3/user/autocorr (Linux) or > \Users\<user>\AppData\Roaming\LibreOffice\3\user\autocorr (Windows) On MacOS X, the autocorrect folder is located at ~/Library/Application Support/LibreOffice/3/user/autocorr
ditto, for me it takes of the order of two seconds; not so good, but not -so- slow either. I agree that it's not a most-annoying bug on that basis. Having said that - if someone invests the time to create a callgrind profile of just this bit, I'm most happy to look at improving it.
@Roman @Micheal maybe you guys work on very fast machines which helps not noticing the issue which maybe is also less evident on MacOS and Linux. however I have to sadly confirm than on my system (Windows Vista 64bit Intel Centrino 2, 2.27 GHz, 4GB RAM) the performance is very slow... the freeze time after adding a new entry and hitting the OK button varies from 15 seconds to even 60 seconds if I added more entries... having said that, I'm not criticizing the 3.5.x MAB removal... I accept this decision and I hope that some Linux user could provide that callgrind testing needed to debug.
I start thinking this issue is Windows related. I tried with an high-performance PC (Win7 ultimate sp1 64bit; Intel Xeon @2.66 Ghz 2 processors; 8 GB RAM) and I still experience 15-60 seconds freeze. this contrasts with reports from Micheal and Roman that experiences just a few seconds delay on Linux and Mac. so the issue doesn't depend on PC power but rather on O/S. the same freeze happens with hi-performance Win7-64bit, medium-performance Vista 64-bit and low-performance XP-32bit computers. so it's not annoying on Mac and Linux but it's annoying on Windows
Created attachment 61815 [details] autocorrect save freeze I'm attaching a screen recording showing a 40 seconds freeze after saving a single new entry to my autocorrect database. test done on Windows Vista 64bit (computer components are described in Comment 5). that's very annoyoing so I'm thinking about adding it again to the 3.5.x MAB page.
Please - install a Linux virtual machine, install a build with debug symbols, and run it under callgrind. Post the callgrind.out.12235 file, and then we can trivially fix it. The video is not useful - no-one doubts that this operation is slow; the big piece of the work is replicating your system to the point that we can do the profiling to get the above: that is most-likely 95% of the work to fix it - and all of it can be done by a motivated user. As/when a profile is there, made vs. a build with debug info - I will personally fix it for you.
Ok Micheal, I'll try my best... I have no experience at all with Linux but I have to start from somewhere...
my only concern is that -as it seems- the issue is more prominent on Windows (15-60 seconds) than Linux/Max (2-3 seconds according to above posts). so I wonder if a callgrind on Linux would disclose what's causing a longer freeze on Windows...
(In reply to comment #8) > Please - install a Linux virtual machine, install a build with debug symbols, > and run it under callgrind. > > Post the callgrind.out.12235 file, and then we can trivially fix it. [...] are the precompiled binaries releases for Linux x86 built with debug symbols? I downloaded the pre-release of LibreOffice 3.5.4 (3.5.4rc1) started callgrind valgrind --tool=callgrind swriter but no info were written in *.out resulting file with: valgrind --tool=callgrind --trace-children=yes swriter I obtained these *.out files - http://ge.tt/6pw1TvH/v/0 what specific callgrind switches are needed to get info you need?
@dingodog probably the test should be done on particular LibO builds with debug symbols. check this link: http://packages.debian.org/experimental/libreoffice-dbg
@ Micheal Meeks in the meantime I tried to get a profile of the issue on a regular LibO 3.5.3 running on Windows using Very Sleepy 0.82 which should be a similar tool to valgrind for Linux. my guess is that a better understanding of the bug could be achieved on the same O/S where the bug is worst... the freeze in Linux is very short compared to Windows. here's the files that the Very Sleepy software generated: http://www.sendspace.com/file/u0ou9p (the .zip contains a .csv file and a proprietary extension .sleepy file) I do not know if those file can be interpreted correctly by you and and I do not know if I did it the right way (it was the first time I used such kind of software) remember that I did not use a build with debug symbols... but if it's necessary I'll download one for Windows from this link: http://dev-builds.libreoffice.org/win32-debug/libreoffice-3-5/ and and I'll try replicating again the test on Very Sleepy
> remember that I did not use a build with debug symbols... > but if it's necessary I'll download one for Windows from this link: unfortunately, without debugging symbols the output will be useless. It's fine to use a windows / sampling profiler, the problem is so big it would be hard for it not to find it ;-) but without a stack-trace it will just generate meaningless hexadecimal garbage. Also - please attach small attachments here; sendspace seems to be some mass of advertising, and I couldn't work out how to download your .zip - it gave me a .exe ;-) Thanks !
Also - you can download a master build with symbols here: http://dev-builds.libreoffice.org/daily/W2008R2@20-With-Symbol-Bytemark-Hosting/master/current/
Hi dindodog, > are the precompiled binaries releases for Linux x86 built with debug symbols? > I downloaded the pre-release of LibreOffice 3.5.4 (3.5.4rc1) No - the debuginfo is rather large, it would double the size of the download. So you would prolly want to just use the version from your linux distribution and install the 'debuginfo' package - the slowness is an old problem so there is no need for a really new build I think. > what specific callgrind switches are needed to get info you need? Good point :-) I use: export OOO_DISABLE_RECOVERY=1 valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin -writer --splash-pipe=0 You need to be able to write to the application's directory so: sudo chmod a+rw . or something first. It'd be great to have a wiki page on profiling and/or to update any existing ones if there are any. Thanks !
(In reply to comment #16) > the debuginfo is rather large, it would double the size of the download. > So you would prolly want to just use the version from your linux distribution > and install the 'debuginfo' package - the slowness is an old problem so there > is no need for a really new build I think. [...] any url for these packages from libreoffice servers?
Created attachment 62035 [details] profile from Very Sleepy Here's a profile output from LibO 3.5.3 dev with debug symbols captured with Very Sleepy 0.82. I started the recording just before hitting "ok" to save the new added entry to the replacement table.
just curious to know if the profile I obtained with Very Sleepy on Windows is somewhat useful to debug.
Rather a hard to read profile from Very Sleepy - what do the columns mean in the CSV file, eg. this looks bad: SvTreeEntryList::remove 2.568197 79.886709 0.326782 10.164923 svtlo [unknown] It'd be nice to work out where that is getting called from and get a stack trace: the nice thing about callgrind of course is that it gives a full, hierarchical map of what is called from where, that makes fixing this stuff really really easy. No doubt something quite silly happening there.
Using LibO 3.5.4 on Ubuntu 12.04 x64, the callgrind log is at: http://www.mediafire.com/?1urd2y4y5qvgorj Hope it helps
(In reply to comment #21) Forgot to say: after step 6, I left the computer and got out to have a meal. When I got back, it finished and I did step 7. I don't know whether this alters the result log. Thanks again.
(In reply to comment #21) > Using LibO 3.5.4 on Ubuntu 12.04 x64, the callgrind log is at: > http://www.mediafire.com/?1urd2y4y5qvgorj > > Hope it helps thank you very much!!! I hope that Micheal Meeks is still available to fix it
(In reply to comment #23) > (In reply to comment #21) > > Using LibO 3.5.4 on Ubuntu 12.04 x64, the callgrind log is at: > > http://www.mediafire.com/?1urd2y4y5qvgorj > > > > Hope it helps > > > thank you very much!!! I hope that Micheal Meeks is still available to fix it hi Michael, I don't want to seem pushy, but I just wanted to know if you are aware of the backtrace provided by Korrawit
> hi Michael, I don't want to seem pushy, but I just wanted to know > if you are aware of the backtrace provided by Korrawit Drat - I missed that :-) Poking at the trace (thanks for that) in kcachegrind - it seems like a big chunk of the problem is here: SvLBoxString::InitViewData(SvLBox*,SvLBoxEntry *, SvViewDataItem *) Which is called 484,000 times - and chews up 25% of the total time (including startup etc.) mostly in measuring text via. OutputDevice::GetTextWidth() That's fun :-) That in turn is called from SvLBox::RecalcViewData - which is called 11 times (seems odd), from SvTreeListBox::SetFont - which is called 9x times (odd). That is called from SvTreeListBox::PaintEntry1 - which is called 80x times - so, perhaps if we can work out what's up with changing the font there, we could get a 10x speedup of that piece. I've easy-hackified this, hopefully that'll increase interest. Thanks for the trace !
Yes, let's hope that as an easy hack this issue will be soon fixed. As an additional information, the “freeze” only happens when saving new entries in the “replacement table GUI mode”. If you save a new entry with “right click autocorrect suggestions” there's no freeze at all, so I suspect that there's something wrong with the GUI mode.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3da2a6a58784a3c607ea4e440865478f1a4fe56e fdo#49350 Speedup entry painting for SvTreeListBox The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Tomaz tested on master 2012-09-20_23.38.37 I actually see no difference in freeze time after adding a new autocorrect entry. Maybe that daily build did not yet include your freeze or the fix was not effective.
Hi, The fix is already in master 2012-09-20_23.38.37 - I tested this build now. This fix primary speeds up changing of selection in auto-correct dialog. You can see the difference when holding up or down key so the selection changes in the list. This was too slow in Linux but bearable when I tested it in Windows. Now it is fast in both environments. Inserting should be a little faster too - for me inserting a new entry in Linux was 8 sec. and now it is <1 sec. In Windows I don't see any difference at inserting - it is fast <1 sec. The biggest delay left for me now is when you click OK - on this action all the entries are synchronized and written into autocorr file and this takes too long IMHO. I will try to improve this. Can you try again and can you put your "merged" autocorr file somewhere so I can test with 100.000+ entries. Regards, Tomaž
Created attachment 67494 [details] huge autocorrect database (119K entries) @ Tomaz as you asked I'm sending you the new autocorrect file for testing. regarding the present issue, the freeze I was talking about was exactly the one that happens when you hit the "OK" button. on my Vista 64bit laptop the master build takes 5 minutes to close and save the replacement table using the 119K entries database... unacceptable... with a smaller database (45K entries) current LibO 3.6.1 takes 40 seconds... still very annoying... (see attachment 61815 [details] ) regarding your fix now I've noticed the difference and I consider it a nice improvement. however the "bottle neck" is still represented by the "OK" freeze that hopefully you will fix as well
(In reply to comment #29) > snip > > The biggest delay left for me now is when you click OK - on this action all the > entries are synchronized and written into autocorr file and this takes too long > IMHO. I will try to improve this. 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). 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... > Can you try again and can you put your "merged" autocorr file somewhere so I > can test with 100.000+ entries. > > Regards, Tomaž did you see my upload?
ok... some more test feedback... DocumentList.xml (which contains all the autocorrect entries) works even if entries are not sorted alphabetically (I manually edited the file changing position of entries and then repacked it as .dat). You can use it even unsorted and the .xml remains unchanged until you add a new entry.... once you do it, either using mouse right click suggestions or manually adding to the autocorrect replacement table, the DocumentList.xml is updated and resorted in alphabetical order. So, the “mouse” and “table” add new entries resorting alphabetically the .xml but the mouse does it a lot faster. We need to discover the reasons of this bad performance of the table. 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?
(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.
(In reply to comment #33) > > 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. -- snip -- that was crazy and explain the worsening performance once the autocorrect database becomes larger > 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. WOW... let me say that I would already be very happy with such time. This is already a drastic improvement from the 6 minutes and 10 seconds I experienced with "z" entries > 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. don't worry, take the time you need. I'm struggling with OOo/Lib autocorrect performance issues from years and I can wait. > 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. mmmhhh... I do not confirm this... from my tests it seems that the acor_.dat file is saved only when you hit OK (I monitored the "last modified" infos on file properties), not after each new added entry... did you actually see time difference when hitting OK after adding a single or multiple new entries? does it always take 12 seconds, regardless of the number of newly added items? P.S. if you have a home-made test build with your latest fixes, I'll be glad to beta test it as well
> > 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. > > mmmhhh... I do not confirm this... from my tests it seems that the acor_.dat > file is saved only when you hit OK (I monitored the "last modified" infos on > file properties), not after each new added entry... I think what he meant was that _after hitting OK_, the file is saved repeatedly for each entry you added.
(In reply to comment #35) > > I think what he meant was that _after hitting OK_, the file is saved repeatedly > for each entry you added. It could be... however if it's like that, he should notice different saving times depending if a single entry or multiple ones have been added. Tomaz said he was able to bring the saving time down to 12 seconds but he did not specify if that time refers to a single entry or more than one.
Hmm.. First time it takes about 12 sec. when adding 3 new entries, second time it takes 6 sec. (probably because the file is cached). If I add only 1 entry it takes 2 sec., 2 entries 4 sec. - So it looks like it really rewrites the acor file for every add/delete. I will need to add a combined command which makes all changes in one step - then probably it will take 2-4 sec. regardless of how many changes are made. P.S. I remembered I use a debug environment for testing - which is not compiler optimized - so it could be even faster in an actual daily build / release. Regards, Tomaž
@Tomaz I'm impressed in your progresses... you are really boosting the autocorrect feature performances!!!
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0513e10635c85fc1aa214948de4992d4b76d555c fdo#49350 Speedup "OK" action of auto-correct dialog The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
unfortunately I cannot beta-test your fix since latest Windows daily does not install... see Bug 55290
(In reply to comment #40) > unfortunately I cannot beta-test your fix since latest Windows daily does > not install... see Bug 55290 In the meantime, you might use this method http://wiki.documentfoundation.org/Installing_in_parallel#Windows
(In reply to comment #41) > (In reply to comment #40) > > unfortunately I cannot beta-test your fix since latest Windows daily does > > not install... see Bug 55290 > > In the meantime, you might use this method > http://wiki.documentfoundation.org/Installing_in_parallel#Windows Cool.. it installs. I tried it with W2008 build which is recent (http://dev-builds.libreoffice.org/daily/W2008R2@16-minimal_build/master/). This one also works in windows 7 (or other windows).
@Korrawit thanks for the hint. I was finally able to install a new LOdev build. @Tomaz tested your fix on master~2012-09-26_20.38.45_LibO_Dev_3.7.0.0.alpha0_Win_x86_install_en-US.msi my first comment is: WOW!! How fast!!! you brought down the saving time from minutes to a few seconds!!! this is a terrific improvement!!! it improves productivity and user experience... no more frustrating waiting time when saving new autocorrect entries!!! so setting this issue as RESOLVED FIXED in LibO dev3.7 now, I hope that your two commits ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=3da2a6a58784a3c607ea4e440865478f1a4fe56e and http://cgit.freedesktop.org/libreoffice/core/commit/?id=0513e10635c85fc1aa214948de4992d4b76d555c ) could be cherry-picked to LibO 3.6.3. I do not know what the correct procedure is... should you ask in the developer's list a patch review in order to push the commits to the 3.6 branch?
(In reply to comment #43) > I do not know what the correct procedure is... should you ask in the > developer's list a patch review in order to push the commits to the 3.6 > branch? Yes. Write an email to developer list with subject: [REVIEW] $an_explanation_here and message with link to the commits.
@Korrawit just to make it clearer... has that mail to be sent from the committ author (Tomaz) or is something that I can even do it myself?
(In reply to comment #45) > just to make it clearer... has that mail to be sent from the committ author > (Tomaz) or is something that I can even do it myself? You can do it yourself. (I already *did* it) Anyway, I'm not sure if the patches will pass the review, especially the second one, because it's large, but I might be wrong of course ;)
Ho hum; we can try getting them reviewed for -3-6 of course; but I'd want the developer of the code to recommend a suitable patch themselves, preferably with a 'diff -w' posted for people to look at, rather than someone un-connected with the implementation. That said - this looks like a really cool fix for a long-standing annoyance. It would be great to add it to: https://wiki.documentfoundation.org/ReleaseNotes/3.7 with suitable credits to developer & testers :-)
(In reply to comment #47) > It would be great to add it to: > > https://wiki.documentfoundation.org/ReleaseNotes/3.7 > > with suitable credits to developer & testers :-) I have already added a short notice there some days ago: https://wiki.documentfoundation.org/ReleaseNotes/3.7#Performance but please improve and exand it!
@Tomaz Vajngerl sorry for keeping bothering you but I still hope that you'll find the time to ask review in the developers list to cherry-picki this Bug 49350 and Bug 48279 to LibO 3.6.3. @Roman good idea, I'll prepare some graphs and text for the wiki page.
(In reply to comment #49) > @Tomaz Vajngerl > > sorry for keeping bothering you but I still hope that you'll find the time > to ask review in the developers list to cherry-picki this Bug 49350 and Bug > 48279 to LibO 3.6.3. > Hi, the problem is that I also have to prepare the patch, not just ask for review. To do this I have to switch to 3.6 development tree, rebuild everything, make changes, test if it works, prepare the patch, ask for review and inclusion and if I want to go back to regular development, switch back to 3.7 tree, rebuild everything again, continue development. For this I need time and hard drive space but currently I want to spend this on something more productive like removing lag when typing in writer when using large autocorrect databases. Also it is probably too late for 3.6.3 anyway. Regards, Tomaž
@Tomaz thank you very much. I was not aware of the effective work needed for a 3.6.x cherry-pick... now that it's clearer to me how the whole thing works, I agree with you: it's better to keep polishing the autocorrect feature in the 3.7.x branch and maybe backport to 3.6.x when everything is fine. I'll be glad to beta-test any of your next fixes.
Migrating Whiteboard tags to Keywords: (EasyHack,DifficultyInteresting,SkillCpp ) [NinjaEdit]