rivo
TextView consumes too much CPU during reindexing/drawing
I've noticed that a simple textview, without colors, regions or wrapping will still consume close to a 100% of a cpu core when its being written to, if it contains a lot of text. A scenario like that is pretty easily achievable if one tries to tail a busy log file via a textview. The bulk of that time is taken by the stringWidth function, either through the decomposeString, later on when calculating the line width for the index itself, and finally during iterateString.
An extremely naive fix was to add a simple map as a cache to the stringWidth util function. This removed the entire bottleneck on subsequent scrolls
I was able to significantly improve the responsiveness of the textview by appending data to the index rather than rebuilding it every time something is written to the buffer. Further optimizations can be had by adding a new parameter to decomposeString to skip calculating the length, since often times it is discarded.
Other things that can be done for even more gains are not rebuilding the index when highlights, colors and regions are changed, but only using or ignoring that information during draw time. This might require a bit more investigation though.
Sorry, I'm just getting to this now. I'd like to understand better where exactly we have the bottlenecks and why they are there (you mentioned stringWidth() - maybe that function needs to be optimized instead). Could you provide a short demo test program that we can use to kind of benchmark this issue?
Yes, the stringWidth function is the bottleneck, and appears to be a big one. Since I wasn't sure it can even be optimized, I decided to optimize everything else around it, which did improve things quite a bit. Most of it is exploiting the fact that the textview can only be appended to, so only then does the index need to be rebuilt.
As for a test program, you can use mine: https://github.com/urandom/kd - if you have a kubernetes cluster lying around. Or you can just stick a decently sized log (a couple of hundred lines should do it) and start appending/scroling in the textview demo code to achieve the same result.
The TextView component has been completely rewritten. It should be much faster now. If you still find that there are problems with it, please open a new issues.