My thanks for Chris and John.
John's suggestion to use the `from-slots' word to provide automatic generic
deserialisation of json is great.
I've been experimenting with serialization using different methods and
different encodings. This thread on github has been raised:
https://github.com/slavapestov/factor/issues/913
Here are some additional observations:
1. `json>' seems more resistant to schema evolution than the `deserialize'.
I saved out my data structure to disk, then changed the shape of my tuple
within the Factor image. My tuple did have four slots; I placed a new slot
of type string in position three; giving the new tuple five slots. On
loading the data using `deserialize', the data that was previously in slot
three was again placed in slot 3, which means the data structure is now
corrupted.
Whereas on re-running the experiment using json, data was restored to the
correct slots, leaving the new slot with an empty string, and correctly
restoring the data to its correct locations.
2. In terms of deserialization speed, using a simple vector containing
tuples, using deserialize in binary mode is fastest. Using json
deserialization (including converting the hashtable to tuples) is about 10%
slower. Surprisingly, deserialize in utf8 mode is slower than json
deserialization, running about 20% slower than deserialize using binary
encoding.
Loryn Jenkins
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
