On 21.06.11 09:13, "Thomas Mueller" <muel...@adobe.com> wrote: >>What about using the >>json library in-memory representations for the microkernel to avoid >>serialization/parsing if not necessary? > >How would that make parsing and serialization _not_ necessary?
That very much depends on what is happing on the client & the implementation of the microkernel. I was thinking that it might be typical that a client has to convert from the JCR API (and an internal representation for it) to the JSON string (serialization) and the microkernel implementation would then have to parse it and convert into its own persistence format. Of course this was just an assumption - if the plan is to leverage the JSON string form 1:1 in the persistence, then this might already work. But I can imagine that sooner or later the kernel will do things like syncing/merging of cluster nodes and might have to actually parse and understand the strings. >Currently, the MicroKernel doesn't fully parse the Json - it just splits >the Json diff into tokens that are substrings of the Json diff. Tokenizing >is faster than parsing because strings don't have to be de-escaped, and >numbers don't have to be parsed. Also, generating the Json is fast because >numbers don't have to be converted to string, and strings don't have to be >escaped. So that's faster than using a regular Json parser / writer as >well. Makes sense, if this will stay this way. > >And because in Java, String.substring creates a string that _shares_ the >character array of the original string, the memory overhead of the >MicroKernel is low (specially if there are a lot of string values, which >seems to be the case). Have you measured it? I only remember the old saying, that Java is only slow because most Java programs do too much string processing, if people compared it to C :-). Sounds like a theoretical discussion doesn't help here, only performance/resource usage comparisons can prove those differences. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
