benchmarks for the release

[Stephen Weeks]

> > Also, as to the wc-input1, which is, indeed, very fine, I must point out that
> > TextIO.inputLine is still too slow.  I think in my tests it was about 1/2
> > the speed of C (with C using the correct #define so that stdio wasn't broken
> > with stupid thread stuff).  My guess was that the problem was the extra copy
> > (and allocation) used to save the characters forming the line.  If that is
> > the cause,  it could be fixed by having some code which read the TextIO
> > buffer but kept the buffers from being re-used.
> 
> A thought i had when browsing through the runtime sources is that a lot of
> those wrapper functions cost us two c-calls with no intervening
> processing.  (I guess if gcc turns them into tail calls, then its like 1.5
> calls.)  Also, I tried implementing the C.c functions as native assembly
> (they are just addressing into a char array), because we pay a C-call when
> copying each byte out of an input string which originally comes in as a
> CString and is then copied to an ML string.  But, it didn't seem to have
> any effect.

Yeah.  I don't think that 1.5-2x cost matters for this.  All we use C
for is the calls to read in to our own text buffer.  inputLine runs
entirely in the ML world except for that.  I don't think it does any
extra work.  It does a single copy (using Array.extract) to produce
the string that it returns.  I don't see how Henry's proposal helps
unless we change the representation of strings to include "sub-arrays"
as a type of string.  That sounds awful both code-wise and
performance-wise to me