Krzysztof wrote:
Well, *great* to see that solved in the Wine core, but I still think I have a bug in RichEdit, because the original (native) riched20 works fast, despite the bug you just fixed.
Is there a good test document for which our riched20 is (with Dan H's patch) still way too slow? If so, let's dig into this.
FWIW, Dan H also explored a change to make a riched "run" struct be refcounted; that gave a 4x speedup. Then he switched to using git bisect to find the cause of the regression, and shelved the refcounting patch. - Dan
On Sun, Jul 02, 2006 at 04:35:11PM -0700, Dan Kegel wrote:
FWIW, Dan H also explored a change to make a riched "run" struct be refcounted; that gave a 4x speedup. Then he switched to using git bisect to find the cause of the regression, and shelved the refcounting patch.
That wasn't the real reason I scratched the refcount idea. To make it work correctly, I had to add copy-on-write and once I did this the performance dropped again. However, the problem I was trying to solve was that ME_SplitRunSimple calls ME_VSplitString, which makes a copy of a large suffix of its string argument. The process then occurs again iteratively on the suffix, so a lot of copys are being made. Instead of this, if we only copied the part of the suffix we need, and then use the same base string in every iteration, we could eliminate another n-squared algorithm.
The 4x speedup might have been, in part, a side effect of something that got broken by the incorrectly reference counted strings. Sorry I didn't mention this before.
-
Dan Hipschman -
Dan Kegel