>Thanks go to Jesper Moller for contributing a patch to fix a Major performance bug in the structured text editor. Bug 236883 was causing major delays when typing or invoking content assistance within the XSD, XML, or other SSE based editors that were in the 500K to 1Meg in size. The root cause of the problem as Jesper has outlined is:
…the entire document was being produced as a string thousands of times
with the sole purpose of calling charAt on it.
The code in question was the following:
document.get().charAt(getReplacementOffset());
The issue is that IDocument get() returns a String, and then charAt was being used to get the character. With large documents this is a major performance degradation. Jesper’s solution is subtle but provides a major speed boost.
document.getChar(getReplacementOffset())
The change is small, but it accomplishes the same thing with out having to retrieve the entire document into a String. This small change alone is something that improves the useability of the SSE based editors, and helps eliminate one of the complaints on slow performance that the Web Tools Editors can have.
I’ve seen major performance boosts in the XML, XSLT, and XSD editors since this change went into place. This change is available in Web Tools Platform 3.1M6 and will be in the Galileo release in June.
intellectualcramps 
>This is also sad. Why are such major performance issues in a “product” that has a 3.1 version number?Has none ever profiled this? Creating thousand of Strings should show on a couple of charts…
>Patrick, I agree that this has taken way to long to address. The problem I’m seeing with eclipse related projects is that they are incuring lots of Technical Debt. Meaning they keep adding features, at the expense of cleaning up bugs from prior features. I’m hoping to work with my fellow Source Editing committers to hopefully use the next couple of point releases to concentrate on the back log and performance issues that cause end user problems.At some point we need to stop and address the technical debt otherwise it just brings the product to its knees.
>Dave, good news:) I would like to transfer to M6 and test it in 2-3 days:)
>There was aa similar issue in Sourceforge days (circa 2004) that was solved for the VEX Editor using profiling. There was a discussion thread on the early VEX project pages.