Hi Tommy,
On Tue, 2012-05-01 at 22:03 +0200, Tommy wrote:
> here's another slowness issue with large replacement table.
> https://bugs.freedesktop.org/show_bug.cgi?id=49350
...
> maybe the same methods applied to previous bugs to speed up things can be
> used here as well
This is rather
On Tue, 01 May 2012 10:34:07 +0200, Michael Meeks
wrote:
Large autocorrect databases cause quite some slowness on first
keystroke for people; turns out we had quite a gratuitous N^2 on load
there involving some ICU collation goodness ;-)
It's still not ideal to have a multi-
On Tue, 01 May 2012 15:21:52 +0200, Tommy wrote:
On Tue, 01 May 2012 14:45:32 +0200, Caolán McNamara
wrote:
On Tue, 2012-05-01 at 09:34 +0100, Michael Meeks wrote:
Large autocorrect databases cause quite some slowness on first
keystroke for people
Looks sane, pushed. Method is n
On Tue, 01 May 2012 14:45:32 +0200, Caolán McNamara
wrote:
On Tue, 2012-05-01 at 09:34 +0100, Michael Meeks wrote:
Large autocorrect databases cause quite some slowness on first
keystroke for people
Looks sane, pushed. Method is not one of beauty.
C.
so this means it will be i
On Tue, 2012-05-01 at 09:34 +0100, Michael Meeks wrote:
> Large autocorrect databases cause quite some slowness on first
> keystroke for people
Looks sane, pushed. Method is not one of beauty.
C.
___
LibreOffice mailing list
LibreOffice@lists.fre
On Tue, 01 May 2012 10:34:07 +0200, Michael Meeks
wrote:
Large autocorrect databases cause quite some slowness on first
keystroke for people; turns out we had quite a gratuitous N^2 on load
there involving some ICU collation goodness ;-)
It's still not ideal to have a multi-
Large autocorrect databases cause quite some slowness on first
keystroke for people; turns out we had quite a gratuitous N^2 on load
there involving some ICU collation goodness ;-)
It's still not ideal to have a multi-second freeze, but at least it's
half the length it was ;-)
