> I'm also now curious whether the string port implementation could be
> sped up at all, perhaps in light of the JIT.
Oh, I just looked at the string output-port C code in Racket 5.0.1, and
I'm kinda wanting to do a pure Racket implementation that is accessible
to the JIT, and see how it compares.
Also, I'm wondering whether consing to store a list of strings from the
write calls without copying would be easier or harder on the GC in
practice than what the current implementation does (i.e., copying each
write into a native allocation, occasionally growing the buffer by
allocating a replacement and copying into it, and copying out a
substring upon "get-output-string"). The first potential problem that
comes to mind for storing a list of allocations from write operations
without copying is that such a string port could turn lots of
short-lived allocations into long-lived ones. Copying the write strings
immediately avoids that problem, but then we're doing a lot more
allocations. I guess I could also try a variation on the current
implementation that grows the buffer by chaining allocations rather than
replacing, which would mean fewer allocations in some cases, but I
suspect that would be a minor improvement at best.
--
http://www.neilvandyke.org/