<div dir="ltr">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.<br><br>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.?<br>
<br>In order to make for instance SSAX-SXML use a custom string port implementation without<br><br> - modifying its code (i.e. changing all I/O operations there are in it to custom ones)<br> - dismaking its compatibility with Gambit's internal I/O functionality (i.e. file ports, TCP ports, etc.)<br>
<br>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?<br>
<br>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?<br><br>M<br><br><div class="gmail_quote">
2008/8/16 Christian Jaeger <span dir="ltr"><<a href="mailto:christian@pflanze.mine.nu">christian@pflanze.mine.nu</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Mikael More wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Marc,<br>
<br>
just to ensure I got your point. You say that one could create a string-port<br>
more than 20 times faster than Gambit's built-in string ports. I'm<br>
interested in the reason - is this because:<br>
<br>
a) If one writes one in scheme code, Gambit may perform function inlining?<br>
b) You presume that the string-port implementation one writes does not need<br>
to be thread-safe, within the context of Gambit's threading system, as is<br>
Gambit's built in string port?<br>
  <br>
</blockquote>
<br></div>
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.<br>
<br>
See my demo at <a href="http://scheme.mine.nu/gambit/experimental/read-char/" target="_blank">http://scheme.mine.nu/gambit/experimental/read-char/</a> (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.<br>

<br>
You really want to clone <a href="http://scheme.mine.nu/gambit/experimental/read-char/.git" target="_blank">http://scheme.mine.nu/gambit/experimental/read-char/.git</a> and look at the history since there you find the benchmark results.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Any more reasons?<br>
<br>
Also, what further reasons do you see as to why a SSAX-SXML XML to SXML<br>
deserialization that takes 3 seconds in Java takes 50 seconds in Gambit?<br>
</blockquote>
<br></div>
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.<br><font color="#888888">
<br>
Christian.<br>
<br>
</font></blockquote></div><br></div>