Execution times and other issues in changing TextEdit documents

Question

(HNY -- back to terrorize everyone with off-the-wall questions)
--This relates to other questions I've asked recently, but that may be neither here nor there.
--Basically, I want to change a specific character in an open TextEdit document, in text that can be pretty lengthy. But I don't want pre-existing formatting of the text to change.
--For test purposes the front TextEdit document is simply an unbroken string of letters (say, all "q's") ranging in number from 5 and upwards. Following are some of the results I've gotten:
--1) Using a do shell script routine (below), the execution is very fast, well under 0.1 second for changing 250 q's to e's and changing the front document. The problem is that the formatting of the first character becomes the formatting for the entire string (in fact, for the entire document if there is subsequent text). So that doesn't meet my needs, although I certainly like the speed.
--SCRIPT 1
tell application "TextEdit"
set T to text of front document
set Tnew to do shell script "echo " & quoted form of T & " | sed 's/q/e/g'"
set text of front document to Tnew
end tell
--END SCRIPT 1
--The only practical way I've found to change a character AND maintain formatting is the "set every character where it is "q" to "e"" routine (below). But, for long text, I've run into a serious execution speed problem. For example, if the string consists of 10 q's, the script executes in about 0.03 second. If the string is 40 characters, the execution is 0.14 second, a roughly linear increase. If the string is 100 characters, the execution is 2.00 seconds, which doesn't correlate to a linear increase at all. And if the string is 250 characters, I'm looking at 70 seconds. At some point, increasing the number of string characters leads to a timeout or stall. One interesting aspect of this is that, if only the last 4 characters (example) of the 250-character string are "q", then the execution time is again very quick.
--SCRIPT 2
tell application "TextEdit"
set T to text of front document
tell text of front document
set every character where it is "q" to "e"
end tell
end tell
--END SCRIPT 2
--Any insight into this issue (or workaround) will be appreciated.
--In the real world, I most often encounter the issue when trying to deal with spaces in long text, which can be numerous.

Answer 1

OK, Camelot, helpful but maddening. Based on your response. I elected to look at this some more, even though I'm stuck with TextEdit on this project. Here's what I found, not necessarily in the order I did things:
1) I ran your "repeat" script on my usual machine (2.7 PPC with 10.4.6)) and was surprised to consisently get about 4.25 seconds -- I didn't think it should matter, but I happened to run it with Script Debugger.
2) Then, curious as to what a slower processor speed would do, I ran it at ancient history speed -- a 7500 souped up to 700 MHz. On a 10.4.6 partition, the execution time was about 17 seconds, but on a 10.3.6 partition it was only about 9.5 seconds. (The other complication with this older machine is that it uses XPostFacto to accommodate OS X.) And I don't have Script Debugger for 10.3.x, so I ran the script in Script Editor on that partition.
3) That got me wondering about Script Editor vs. Script Debugger, so (using 10.4.6) I ran the script on both the old machine and my (fast) usual machine using Script Editor. On the old machine, it was somewhat faster at about 14 seconds. But, surprise!, on the current machine it took twice as long at 8.6 seconds. The story doesn't end here.
(BTW, I added a "ticks" routine to the script, so the method of measuring time should be consistent. And I've been copying and pasting the script to the various editors, so there shouldn't be any inconsistencies with it. I've consistently used a 250-character unbroken string of the target in a TextEdit document.)
4) Mixed in with all these trials, I wrote a script to get a list of offsets of all the target characters; it can be configured to change the characters or not. But I found some intriguing SE vs. SD differences there also. In tests on the fast machine, running the script simply to get the offset list (without making any changes), the list is generated in under a second -- but sometimes barely so. The surprise was that SE ran it in about half the time as SD. although SD was about twice as fast with a script that called for changes. Go figure.
5) Since getting the offset list is pretty fast in either case, I was hoping to think up some innovative way of using the offset list to make changes in the document more quickly. But running a repeat routine with the list simply isn't innovative, and the result is roughly what I get with your repeat script coupled with an added fraction of a second for generating the list. Changing each character as each offset is generated also yields about the same result.
My conclusion from all this is that the very fast approaches (which lose formatting) are changing the characters globally, not one at a time as occurs visibly with techniques where the formatting isn't lost. I don't know what to make of SE vs. SD, but I repeated the runs several times in each editor, with consistent results.
Finally, while writing the offset list script, I encountered a couple AS issues that I've seen several times in the past (having nothing specifically to do with this topic), but I'll present that as a new post.
Thanks for your comments and any others will be welcome.