ObjectMapper's serialized object caching

[Matteo Olivi]

Hello,

Do Jackson ObjectMappers cache serialized objects?

I'm writing a benchmark to test which serialization format is faster. For each serialization format, one ObjectMapper for the format is instantiated (by passing the factory for the given serialization format to the ObjectMapper constructor). The same ObjectMapper instance is then used to serialize the same object multiple times, and my code prints the time it took to serialize the object for each iteration. I've noticed that for every format the first iteration always takes way longer than the others (e.g. 83 ms at first iteration vs =~ 20ms at others). This is true when deserializing objects too.

IMO there are two possible reasons:

1) The JVM or the ObjectMapper allocates memory for some data structure lazily, and this needs to be done only once, so the first iteration always takes longer.

2) The ObjectMapper keeps a cache of serialized objects. If this is true the results printed from my benchmark are garbage.

I did a test where at every iteration one field of the object to serialize is mutated, and I observed the same phenomena (slow first iteration), so this seems to rule out caching, but I want to be 100% confident.

Thanks,

Matteo.

[Tatu Saloranta]

ObjectMapper does not cache objects it serializers, so benchmark is
not flawed in that way.

But there is definitely quite a bit first-time work to be done for
constructing all handlers for given type, including serializer(s):
these are cached.
In addition the thing to know about JVM benchmarking is that there is
a lot of optimization for byte code that happens over time, and not
right away: for example just-in-time compilation of (some of) byte
code into native code. So it is very typical for initial run times
(for first couple of seconds) to be much slower than later runs.

I hope this helps,

-+ Tatu +-

[Matteo Olivi]

That was thorough and clear. Thanks!

[Guido Medina]

I'm quite certain Jackson is caching only the classes information like methods annotations, etc; that's why the 1st iteration is slow,

you don't want to do all the reflection information gathering every single time you serialize/de-serialize an object.

We serialized/de-serialized millions of objects so if number 2 would had been true we would had seen out of memory errors long time ago.

Think, to cache something you need to make sure there there is proper hash code and equality defined in the classes which is way outside the scope of what Jackson libraries do.

Also; to cache something in a map for example you need a key, how in the world Jackson would had any context of what key to use to store values?

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/9a2e7f80-d7c9-4093-85ed-15a1d45745d7%40googlegroups.com.