Scaling issue in the "lift" and "transform" stages

[quark17]

The example given in this discussion comment shows a scaling issue as the number of system task calls increases:

package ReadManyBytes where

import Vector

type N = 16

mkReadManyBytes :: Module (Empty)
mkReadManyBytes = module
  rules
    {-# ASSERT no implicit conditions #-}  {-# ASSERT fire when enabled #-}
    "foo": when True ==> do
      opened :: File <- $fopen "my_file" "r"
      x :: Vector N (Int 32) <- mapM (\_ -> $fgetc opened) _
      if (any (\c -> c < 0) x) then do
        $display "Got EOF"
      else do
        mapM_ (\c -> $write "%c" c) x
        $display  -- Newline
      $fclose opened
      $finish

This example replicates $fgetc many times and then replicates $write many times. The scaling issue seems to be most severe with $write in this case. Details are in the replies to the discussion comment, but I'll summarize. At size 128, the first transform is a few seconds, and the later lift and transform stages are 20-30 seconds; at size 512, the first transform is 25 seconds, the lift is 200, and the the second transform runs out of stack (even at 10M, would be worth trying larger). If the replicated $write is removed (or is replaced with a single display of the whole vector), then first transform still takes 25 seconds, but the later lift and transform take no time.