I see your point - if one writes a string-port, with completely custom open, read, write, close operations, one can achieve a lot higher speeds than if using Gambit's built-in I/O.

Though, are the higher speeds Marc addressed reachable while still using Gambit built-in I/O operations, such as read, write, read-char, display, etc.?

In order to make for instance SSAX-SXML use a custom string port implementation without

 - modifying its code (i.e. changing all I/O operations there are in it to custom ones)
 - dismaking its compatibility with Gambit's internal I/O functionality (i.e. file ports, TCP ports, etc.)

one needs to run this port implementation atop/behind/under/using Gambit's built-in I/O system. So, is it possible to increase the speed of the string port implementation a lot, while still running on Gambit's built-in I/O?

If not, perhaps one would benefit from writing a custom buffered IO layer atop Gambit-s built-in IO, and then patch SSAX-SXML to use it. That ought to give blazingly high speeds, correct?

M

2008/8/16 Christian Jaeger <christian@pflanze.mine.nu>
Mikael More wrote:
Marc,

just to ensure I got your point. You say that one could create a string-port
more than 20 times faster than Gambit's built-in string ports. I'm
interested in the reason - is this because:

a) If one writes one in scheme code, Gambit may perform function inlining?
b) You presume that the string-port implementation one writes does not need
to be thread-safe, within the context of Gambit's threading system, as is
Gambit's built in string port?
 

It's both because of read-char requiring a real cross-module Scheme call (it is not being inlined) but also because it is implemented thread safe, i.e. using a (Gambit) mutex internally.

See my demo at http://scheme.mine.nu/gambit/experimental/read-char/ (which just a rehash of what Brad Lucier showed on the mailing list in february 2007 in the "fast csv parser" thread) where I showed that to someone on IRC.

You really want to clone http://scheme.mine.nu/gambit/experimental/read-char/.git and look at the history since there you find the benchmark results.


Any more reasons?

Also, what further reasons do you see as to why a SSAX-SXML XML to SXML
deserialization that takes 3 seconds in Java takes 50 seconds in Gambit?

You could take a look at the Java code. Probably it isn't reading from the input in single chars with mutex locking for each of them.

Christian.