With a quick glance through your code, this jumps out as being woefully inefficient:First off, it's creating a large number of String objects which shortly become eligible for GC; then, it splits on a single whitespace rather than multiple whitespace with multiline (see the docs for java.util.regex.Pattern and/or a regex tutorial).
Take a look at the methods of javax.swing.text.Utilities; I would expect that using those methods in conjunction with Document#getText(...) would be more efficient than your present approach. But you also need to rethink your design to examine only the part of the Document that has been changed -- probably in the DocumentFilter. Examining the entire text is always going to be slow for large files.
There are no new questions, but there may be new answers.
Darryl Burke wrote:If you can make an SSCCE that shows the specific problem and does nothing else, I might take a look. Provided that can be done in a short enough code.
Thanks a lot for the reply. OK, I have omitted most of my code, and reduced it to 163 lines. From line 123-126, you will see my failed attempt, in COMMENTS. Here is the code, it is changed, but it still uses the other class and interface which I have posted above, Below is my edited "Form.java" code.
I'm a little tied up with something else (and shall be for most of the coming week) but this is precisely what I have been advising against:Without having tried it, I feel you can use the methods of the Utilities class so that you examine only the complete words around the offset.
I rather think you need to also pass the length of the inserted string, for an insertion. Then use getPreviousWord(...) for the offset, and getNextWord(...) for the offset+string.length() and examine and highlight only within that range. Why search through a whole lot of stuff that hasn't just changed?