I suspect this phenomenon is related to my topic on hanging with right click on selected text, but it is more general.

I have an execution group (in a standard worksheet in worksheet mode with 2D input) with about 65 lines (when comment lines are included) and 30 lines (when comment lines are removed) . It was taking a very long time to compute after each time I changed anything in the group, but computed very quickly thereafter if I changed nothing. After some experimenting, I discovered the following phenomenon.

I put another execution group just before this problem group which only saved the output of time(). Then I inserted a first line in the problem group which calculated the elapsed time before it started. I also resaved the time from that point and calculated the elapsed time at the end of the problem execution group. The time (when comments were included) was 80 sec to start up the new execution group the first time and about 5-6 sec to actually do the computing. I am conjecturing that the 80 sec was some sort of parsing that has to be done on the code the first time through. Subsequent executions yielded 0 sec "parse" time instead of the 80 sec. Interestingly, if I simply removed all the comment lines, the "parse" time whent to 23 sec. Apparently, to set up lines to ignore takes almost a minute by itself. Note that the "parsing" time varies from 4 to about 12 times actual computing time.

Now, the question that comes to mind is "Is there something really difficult about how my code is expressed?"  To test that, I converted that execution group to classical 1D format using the menu Format>Convert function (which interestingly, leaves out all the comments). That always zips through with no parsing time, whether I have just edited the text or not, although it does seem to take about 2 sec longer to compute. However, a gain of 2 sec time in computing in no way makes up for the 80 sec lost in parsing each time I edit (since I do not want to give up the important comment lines documenting the code). After all, Maple is supposed to be an interactive program not a compiled program.

Actually, this execution group is on a worksheet inputed  by a student. However, there is nothing obviously essentially different about the two versions, although the student version does use some different variable names and the order of the code lines is somewhat different. The execution group that I entered has only about 6 sec (even with the comment lines) of parsing time if I change something. This leads me to suspect that there are some hidden bytes in the student's version that are causing the problem. Clearly converting to 1D format eliminates those hidden bytes while not changing any visible information except its typographical format. And the converted code runs fine, producing the expected output. Thus converting to 1D format doesn't reveal where the problem is. The problem seems to be peculiar to the 2D input format in the standard worksheet.

Clearly the 2D input has a continuously running "parsing" process. It will, for instance, not allow one to split a line of code with a Shift-Enter when the insertion point is inside a procedure's parentheses, list's square brackets, etc. To do this split, one has to first delete the closing parenthesis, etc., and then restore it after the split. (Trying the split without the deletion, moves just the semicolon at the end of the statement to the next line.) This never happens in 1D format; in that format, each character is just that character with no connections to other characters. Thus the 2D format must have hidden pointers.

Experience also tells me that problems often occur when individual variable names are edited. Depending on the timing of the steps in editing the name, the final result may look absolutely fine, but give errors like "use of object as a name" (not, unfortunately, indication what name is causing the problem). The only solution is to start retyping recently edited names. When the guilty name is retyped, all works well. Visually, of course, nothing has changed by the retyping.

There needs to be some kind of tools to dig out these offending bytes!