jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: [j3] Repository MicroKernel API draft
Date Tue, 21 Jun 2011 07:33:26 GMT
On 21.06.11 09:13, "Thomas Mueller" <mueller@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


Mime
View raw message