At first we are looking at a practical example, generated with application Scidb (with the use of command inspect). Note that this script needs the data file "Game.dat". Also note that this example will look a bit weird if the chess fonts are not installed on your system, but this example also works without these fonts.

proc Load {content} {
  pack [text .t] -expand yes -fill both
  # the revised version could use "load" instead:
  # .t load $content
  foreach seg $content {
    lassign $seg type arg1 arg2 arg3
    switch $type {
      setup     { .t configure {*}$arg2 }
      configure { .t tag configure $arg1 {*}$arg2 }
      bind      { .t tag bind $arg1 $arg2 $arg3 }
      text      { .t insert end $arg1 $arg2 }
      break     { .t insert end "\n" $arg1 }
      left      { .t mark set $arg1 end; .t mark gravity $arg1 left }
      right     { .t mark set $arg1 end }
    }
  }
}

set fp [open "Game.dat" r]
Load [read $fp]
close $fp
.t configure -state disabled
update
if {[catch { .t sync }]} {
  .t count -update -ypixels 1.0 end ;# works with wish8.5
}

The loading time (this also includes the computation of the line metric) is much faster in revised version. But the difference in look & feel is even more important:

• Try to scroll down, and then scroll up, with old implementation especially up-scrolling feels to be impossible, it hangs for some seconds. The revised implementation is fast and smooth. (Note: when compiled with debug information then it may jerk a bit, because the code contains expensive assertions.)

• Watch the mouse cursor when doing fast hovering (use the area with the long line). The old implementation has a visible delay, but the new implementation is reacting immediately (especially when compiled without assertions).

Now we test the line scrolling behavior with same data (see first example), the following script scrolls down and up.

proc Load {content} {
  pack [text .t] -expand yes -fill both
  # the revised version could use "load" instead:
  # .t load $content
  foreach seg $content {
    lassign $seg type arg1 arg2 arg3
    switch $type {
      setup     { .t configure {*}$arg2 }
      configure { .t tag configure $arg1 {*}$arg2 }
      bind      { .t tag bind $arg1 $arg2 $arg3 }
      text      { .t insert end $arg1 $arg2 }
      break     { .t insert end "\n" $arg1 }
      left      { .t mark set $arg1 end; .t mark gravity $arg1 left }
      right     { .t mark set $arg1 end }
    }
  }
}

set fp [open "Game.dat" r]
Load [read $fp]
close $fp
.t configure -state disabled
update
if {[catch { .t sync }]} {
  .t count -update -ypixels 1.0 end ;# works with wish8.5
}

set n [.t count -displaylines 1.0 end]
for {set i 0} {$i < $n} {incr i} {
  .t yview scroll 1 units; update
}
for {set i 0} {$i < $n} {incr i} {
  .t yview scroll -1 units; update
}
exit 0

It's obvious, the old implementation has severe problems with long lines. I think it's clear that the old implementation is more or less useless when long lines are involved, even the first example is demonstrating this.

The user is simply typing text, 10,000 characters, short lines.

#wm state . withdrawn
pack [text .t -width 80]
update

for {set i 0} {$i < 10000} {incr i} {
  .t insert end "A"
  update
  if {($i + 1) % 80 == 0} {
    .t insert end "\n"
    update
  }
}
if {[catch { .t sync }]} {
  .t count -update -ypixels 1.0 end ;# works with wish8.5
}
exit 0

No significant difference, although insertion of text in revised version is more complex, especially if newlines are involved, like in this test case.

This seems to be the right place to explain one of the differences between wish8.5 and higher versions. The overhead of a function call has been increased since wish8.6, and this overhead does not belong to the text widget, it belongs to the core of the Tcl library. Due to my measurements the overhead of a simple function call is about 30% slower compared to wish8.5. Due to Tcl Performance the non-recursive execution engine imposes a measurable performance penalty; see also Performance difference tcl 8.5 vs 8.6. I think that also the fact, that wish8.5 is not using threads like wish8.6/7, might play a role here.

Appending character by character, and setting many marks with left gravity, when option -steadymarks is set (possible only in revised version).

text .t
catch { .t configure -steadymarks on }

for {set i 0} {$i < 10000} {incr i} {
  .t insert end "A"
  if {($i + 1) % 80 == 0} {
    .t insert end "\n"
  }
  .t mark set $i end
  .t mark gravity $i left
}
exit 0

Setting option -steadymarks has a significant impact on the speed when working with marks. In my opinion the behavior with -steadymarks enabled is more natural than the old behavior (if this option is disabled). And with computed editor layout enabling this option is a must.

Appending character by character, then undo all changes, and then redo all undoes.

pack [text .t -undo on]

for {set i 0} {$i < 10000} {incr i} {
  .t insert end "A"
  if {($i + 1) % 80 == 0} {
    .t insert end "\n"
  }
  # Makes no big difference in time when included:
  #.t edit separator
}
.t edit undo
.t edit redo
exit 0

The old mechanism is very slow, the revised implementation is directly working with the segment chains, the difference in speed is enourmous. Even the memory handling is better with new implementation.

Note that performance tests with wish8.7 are not possible. The undo operations now are computing the affected ranges, and the implementation of this feature seems to have leastwise polynomial computation time.

Appending character by character to same (long) line.

pack [text .t]
update
for {set n 1} {$n <= 2000} {incr n} {
  .t insert end "a"
  update
  if {[catch { .t sync }]} {
    .t count -update -ypixels 1.0 end ;# works with wish8.5
  }
}
exit 0

The old implementation needs significantly more allocations (and deallocations) than the revised implementation in this case, so finally the revised implementation is a little bit faster, although inserting a character is a bit more complex with revised implementation.

Appending character by character to same (long) line, but now every character will be tagged, in total only 10 different tags will be used.

pack [text .t]
for {set n 1} {$n <= 5000} {incr n} {
  .t insert end "a" [expr {$n % 10}]
}
exit 0

The behavior of the old implementation is a catastrophe, especially the performance killer CleanupLine is responsible for this desaster, but also SplitSeg performs poorly.

Note that this example is not unrealistic: for example, the user will show some data from scientific test series, quite often this kind of data has no newlines.

Inserting 1,000,000 lines.

pack [text .t]
.t insert end [string repeat "1\n" 1000000]
update
if {[catch { .t sync }]} {
  .t count -update -ypixels 1.0 end ;# works with wish8.5
}
exit 0

This shows that the revised implementation needs more memory for line management, and B-Tree management. But take into account that this example is a bit extreme, it is demonstrating (nearly) the worst case. And remember that the polynomial computation time (long line problem) of old implementation has been eliminated, but the memory increase is only linear.

Inserting 1,000,000 lines, hiding (adding elision) most lines, and applying command get -displaychars 100 times.

pack [text .t]
.t insert end [string repeat "1\n" 1000000]
.t tag configure hidden -elide on
.t tag add hidden 2.0 1000000.0
for {set i 0} {$i < 100} {incr i} {
  .t get -displaychars 1.0 end
}
exit 0

This is one example that the handling of elided text is very fast in revised version.

Inserting a longer line, each character is tagged, then positioning the insert cursor 100 times.

pack [text .t]
update
for {set i 0} {$i < 500} {incr i} {
  .t insert end $i $i
}
for {set i 0} {$i < 100} {incr i} {
  .t mark set insert 1.$i
  update
}
exit 0

The old display stuff is slow, even when simply re-drawing the insert cursor.

Count the number of display lines between randomly chosen text positions (with use of count -displaylines).

pack [text .t -wrap word]
set text [string repeat "test " 60]
append text "\n"
for {set i 0} {$i < 1000} {incr i} {
  .t insert end $text
}
update
if {[catch { .t sync }]} {
  .t count -update -ypixels 1.0 end ;# works with wish8.5
}
update

proc rand {max} {
  set value [expr int([expr rand()*100])]
  set value [expr [expr $value % ($max + 1)]]
  return $value
}

expr {srand(2838783)}
set n [.t count -displaylines 1.0 end]
set k [.t count -indices 1.0 1.end]
for {set i 0} {$i < 10000} {incr i} {
  set row1 [rand $n]; set row2 [rand $n]
  set col1 [rand $k]; set col2 [rand $k]
  # we need: (row1,col1) <= (row2,col2)
  if {$row1 > $row2} {
    set tmp $row1; set row1 $row2; set row2 $tmp
  } elseif {$row1 == $row2 && $col1 > $col2} {
    set tmp $col1; set col1 $col2; set col2 $tmp
  }
  .t count -displaylines $row1.$col1 $row2.$col2
}
exit 0

This is another example about the increase of speed in display stuff. However, the old implementation of count -displaylines is a bit of a desaster.

Adding and removing tags within large ranges.

text .t
.t insert end [string range [string repeat "This line contains text.\n" 100000] 0 end-1]
update
if {[catch { .t sync }]} {
  .t count -update -ypixels 1.0 end ;# works with wish8.5
}
for {set k 0} {$k < 10} {incr k} {
  for {set i 0} {$i < 5} {incr i} {
    .t tag add tag$i 1.0 end
    update
  }
  for {set i 0} {$i < 5} {incr i} {
    .t tag remove tag$i 1.0 end
    update
  }
}
exit 0

As already mentioned (on page New Implementation of Tag Handling), adding and removal of tags now is more expensive, especially with large tag ranges – but the lookup of tag information is super-fast with new implementation.

This is another test case which shows one drawback of the new implementation, it is consuming more memory. Currently this is the only known drawback.

Add and delete one tag repeatedly, with the use of tag add/delete, only short ranges.

pack [text .t]
set line [string repeat "Test " 20]\n
.t insert end [string repeat $line 1000]
for {set i 0} {$i < 10000} {incr i} {
  .t tag delete t
  foreach {a b} {1.2 1.5 2.1 2.5 5.2 7.4 8.1 40.1 998.0 999.0} {
    .t tag add t $a $b
  }
}
exit 0

The revised version is about 100% slower when adding/deleting tags. The lookup of tags is super-fast now (the first two test cases are demonstrating this), but adding/deleting has slowed down a bit, the new tag handling implementation is quite more complex.

Search forward for tagged ranges, with the use of tag nextrange.

pack [text .t]
set line [string repeat "Test " 20]\n
.t insert end [string repeat $line 1000]
foreach {a b} {1.2 1.5 2.1 2.5 5.2 7.4 8.1 40.1 998.0 999.0} {
 .t tag add t $a $b
}
for {set i 0} {$i < 10000} {incr i} {
  set pos 1.0
  while {[llength [set r [.t tag nextrange t $pos end]]] > 0} {
    set pos [lindex $r 1]
  }
}
exit 0

No difference in time when searching tags. It's important that searching for tagged ranges is still fast, because the handling of tags has been completely changed, and the new search algorithm is more complicated than the old one (but the complexity in time is still the same).

Inserting some short lines with tagged text, we use 100 different tags (not very much). Note that this script expects a loop count as parameter. The widget will be cleared in each iteration step.

text .t

for {set n 0} {$n < [lindex $::argv 0]} {incr n} {
  if {[catch { .t clear }]} { ;# only works with revised version
    .t delete 1.0 end ;# but this works with old version
    # the following makes no difference in performance, or memory handling
    # .t tag delete [.t tag names]
  }
  for {set i 0} {$i < 1000} {incr i} {
    if {$i > 0 && $i % 60 == 0} {
      .t insert end "\n" ;# we want short lines
    }
    # insert a tagged uppercase letter
    .t insert end [format "%c" [expr {($i % 24) + 65}]] tag[expr {$i % 100}]
  }
}

exit 0

Firstly we test with loop count 1: "wish perf-15.tcl 1".

Secondly we test with loop count 10: "wish perf-15.tcl 10".

Thirdly we test with loop count 100: "wish perf-15.tcl 100".

This shows that the re-use of a text widget (after deleting the whole content) performs much better with revised version, the difference is enormous. The more tags, the higher the performance improvement (based on tests).