I reran a 256  subset of Charles' `output' file.
In an xterm with an rcons-sized font, it took 5.7 seconds.

On rcons, on the same hardware (no reboot), it took 70-some seconds.
Another flat profile (skipping contributors under 1%):



Each sample counts as 0.00390625 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 65.63     75.82    75.82   255872     0.30     0.30  raster_op_noclip
 11.47     89.08    13.26                             kernel_text
  3.74     93.40     4.32                             __mcount
  1.93     95.63     2.23   138440     0.02     0.03  vn_read
  1.21     97.03     1.40   141211     0.01     0.59  syscall


The dynamic call-graph says the expensive calls to raster_op_noclip()
are coming via rcons_textn():

-----------------------------------------------
               75.82    0.00  255872/255872      raster_textn [12]
[13]    77.4   75.82    0.00  255872         raster_op_noclip [13]
-----------------------------------------------

Now, wscons_rops.c uses rcons_textn to do painting, just like rcons
does (via rcons_text(), via rcons_puts()). Which indicates that
nonaccelerated, raster-based text displays will have the same abysmal
performance as rcons.

What's the status of using wscons on ports that currently use rcons--
or which use PROMs to avoid rcons sad performance?