[Chicken-users] Some findings (WAS: Re: ANN: new eggs "llrb-syntax" and "llrb-tree")

[Jörg F. Wittenberger]

Am 24.10.2015 um 20:57 schrieb "Jörg F. Wittenberger":

> 4) string->symbol puts #3 upside down:
> string->symbol 1000000 calls in 111935.0 ms
> caching the result in a LLRB-string tree naturally adds overhead on the
> first call: str2sym 1000000 refs in 185748.0ms – almost twice.
> Wait, what? *Almost* twice?  How comes?  Should have been around 230%
> according to #3.
> 
> But on the second call string->symbol still takes those 112403.0ms,
> while the LLRB-cached version needs only 16321.0ms.

I had to try than in practice.  Summary: makes quite a difference for
me.  YMMV.  If your code does a lot of parsing you may gain from using
mutate-procedure! to replace string->symbol with the caching version.

So "for me" means here ball.askemos.org.  To give you an idea how this
is effected, let me give you some background:  Askemos is to a Schemer
like a persistent Termite.  Roughly.

However what is "the store" in Scheme, where locations are bound to
values becomes a Merkle-tree in Askemos, wherein locations are hashs of
the value.  Much like in version control systems.  And: all values have
a canonical serialization (in 2001 we decided to go with XML).  And
after all: it delivers it's own website, so it should do XML.

The Merkle-tree was a requirement, because the whole idea was to make
something only now becoming popular with projects like crypti.me and
ethereum:  Take human readable code plus source code (sometimes
"ricardian contract"[1]) to create a programming environment with an
transparent audit trail.  Sorry for not trying hard enough: I did not
have a good idea how to include the resulting sha256 code into the tree.
 Therefore no letrec in the store.

So our agent communicate via message passing as in Termite.  They have
access to their own state.  Originally this state was XML, later we
added sqlite.  (Using sqlite's vfs we keep serve it's database directly
from the Merkle tree.)

There is one more difference to a normal Scheme.  Whenever our agent
process a message, this does not happen just locally.  Each agent has an
assigned set of network nodes ("notaries" we call them - nine for the
website, some of which are in the DNS).  All of them receive the
original message and process it according to the "contract code" of the
agent.  Then they ensure that there is a 2/3rd majority of notaries who
signed the same hash key for the new state.  Only then the transaction
is committed to the store.  (IMHO a much better concept to model an
agreement than a proof-of-work.)

...  So much background.  Otherwise it's very much like Scheme.  ;-)


Originally this was written to RScheme.  Knowing that RScheme's symbols
have one slot holding the hash code.  So string->symbol became heavily
used to convert string=? to eq? and optimize hash table lookups.  Now
all those XML tags, all those hashcodes used as locations in the store,
even the hashes of our database blocks pass through string->symbol at a
point.

In this context, a faster string->symbol is quite nice to have.

Best

/Jörg

[1] http://www.webfunds.org/guide/ricardian_implementations.html