Practically all the time that TV is not waiting for user-input or parsing
command sequences is spent copying data around in the buffer. That is why,
when trying to speed-up your macros, it is always vital to look at what
happens to the buffer, rather than how many commands are processed. The
copying-mechanism itself is the most optimized piece of code in TV (on
Amiga, for instance, it is the only part written in assembler, to squeeze
out all that's in the processor).

The following three areas are useful to look into when improving your code:

1. Efficient use of commands

   The golden rule is, to let commands do as much as they can. Three
   examples will illustrate this:

   *  Consider a buffer with ten characters, the cursor positioned at the
      top. The goal is, to remove the first three characters.

      Solution 1: d d d ESC ESC

      Solution 2: 3 d ESC ESC

      Both solutions work. The difference in parser efficiency is negligible.
      Nevertheless, solution 1 stinks. Consider the number of characters TV
      needs to move around. For solution 1, the first d command causes
      characters 2 - 10 to be moved to positions 1 - 9 (9 bytes copied, not
      counting internal administration, but we won't go into that). The
      second d command causes bytes 2 - 9 to be moved to positions 1 - 8
      (so 8 bytes are copied). The last command similarly causes characters
      2 - 8 to be moved to positions 1 - 7 (with 7 bytes copied, making a
      total of 9 + 8 + 7 moves: 24 bytes copied. Looking at solution 2 in
      the same way, the 3d command causes bytes 4 - 10 to be moved to
      positions 1 - 7 (copying 7 bytes). And that's it. Note, that the
      larger the buffer, the more dramatic the difference.

   *  A similar tale may be told for replacements. To replace the string
      string by other_string for all occurences in the buffer, again two
      alternatives are considered:

      Solution 1: < r string ESC other_string ESC > ESC ESC

      Solution 2: h r string ESC other_string ESC ESC

      Apart from not needing an iteration (always a good idea to avoid them
      as much as possible if there is an alternative), the second solution
      has an asset built-in which is not obvious at first sight. Whenever
      TV is asked to do multiple replaces in one go, it does all the partial
      shifting in the buffer in one pass. That is why it will cost almost as
      much time to replace 1 instance of string as it would to replace 20!

   *  The third example is along the same lines. The issue is, this time,
      to insert 10 SPACE-characters. For obvious reasons, alternative 2
      is again vastly preferable:

      Solution 1: 10 < i SPACE ESC > ESC ESC

      Solution 2: 32 , 10 i ESC ESC


2. Work WITH the buffer, not AGAINST it

   It is obviously inefficient to let TV move around characters you will
   be removing later on in the command-sequence anyway. Also, it is not
   efficient to insert characters too soon, so that they must be moved
   around after insertion later on in the command-sequence. This leads to
   two efficiency-rules which seem illogical at first sight:

   Rule 1: INSERTION should be done top-down

   Rule 2: DELETION should be done bottom-up

   The principle is the same in both cases, so an illustration of rule 2
   will have to suffice. Consider a buffer with 10 lines, each with 9
   characters and a RETURN (100 characters in all). Aim is, to remove the
   first five characters from each line.

   Solution 1: j 10 < 5 d l > ESC ESC

   Solution 2: z j 10 < - l 5 d > ESC ESC

   Looking at solution 1, notice that pass 1 moves 95 characters, pass 2
   moves 85, pass 3 75 and so on, totalling at 500 copied bytes.

   For solution 2, pass 1 moves 5 characters, pass 2 moves 10, pass 3 15
   and so on, totalling at 275.

   For large buffers, the impact of this is more than noticeable!

3. Beware of memory fragmentation (Amiga only)

   It is possible that the performance TV gives deteriorates over time. At
   the beginning of a session it may be very rapid, but after a (long)
   while, a certain sluggishness may set in. If this happens, the only
   thing to do is save the work, reboot the machine, and start where you
   left off. The AmigaDOS memory management-system does not cope very well
   with fragmentation - and that's what's happening. Later versions of the
   operating system may be more sturdy, but up until OS3.1 this effect may
   occur.

   NOTE: this slowing down does not mean that TV (or worse: the Amiga
         itself) is about to crash. Only the performance becomes reduced.