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/ _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
