Hi Norbert,
I have only skimmed this thread, so forgive me if i missed the mark but:
why not generate the index at install time ?
that will still achieve the goal of reducing the size of the
installer, without the performance hit at runtime no?
The option to build the index at install time was also discussed and
was the original goal, and has definitely not been ruled out. My
understanding Michael was not keen to do this on Linux, but keen to
try it in the Windows Installer.
From my perspective it was a lot easier to patch some code into
something I could test (mythes) than something I could not (the
windows installer), so I thought I'd start with an easier option.
It is important to keep in mind that the performance hit is once off
per instance of swriter, and happens the first time you right click on
a word in a specific language. With this implementation, once this is
done, the whole index is cached in an STL map so performance should be
around the same as before (lookup a word in an STL Rbtree vs a binary
search on a char ** structure).
It would also be possible to generate a dictionary index on first use,
but of course that would mean having to generate an index per user so
I'm not entertaining that idea seriously.
Regards,
Steven Butler
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.