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.