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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users