Optimize startup time: Jackson

[dsyer]

See also discussion at #7591 and https://github.com/dsyer/spring-boot-startup-bench.

Removing Jackson means removing the actuators as well, as things
stand. But it has quite a dramatic effect (probably Thymeleaf has no
impact at all and we are just seeing Jackson in the results
of #7591). Results:

Benchmark                           Mode  Cnt  Score   Error  Units
PetclinicBenchmark.devtoolsRestart  avgt   10  0.851 ± 0.018   s/op
PetclinicBenchmark.explodedJarMain  avgt   10  2.823 ± 0.075   s/op
PetclinicBenchmark.fatJar           avgt   10  3.895 ± 0.039   s/op
PetclinicBenchmark.noverify         avgt   10  3.397 ± 0.060   s/op

These should be compared with the same thing but fully loaded. Here's a reminder of what
they are:

Benchmark                                   Mode  Cnt  Score   Error  Units
PetclinicBenchmark.devtoolsRestart          avgt   10  1.107 ± 0.054   s/op
PetclinicBenchmark.explodedJarMain          avgt   10  3.618 ± 0.149   s/op
PetclinicBenchmark.fatJar                   avgt   10  5.040 ± 0.229   s/op
PetclinicBenchmark.noverify                 avgt   10  4.402 ± 0.149   s/op

That's pretty huge!

[wilkinsona]

See also #1789. I did some digging at one point into the number of ObjectMapper instances that are created. It's quite a lot, and is more than it ideally would be. I can't find that analysis now (it's in an issue comment somewhere and search is failing me), but one area was code calling MappingJackson2HttpMessageConverter() and then setting the ObjectMapper rather than just calling MappingJackson2HttpMessageConverter(ObjectMapper). The former creates and then throws away an ObjectMapper instance. It was other Spring projects that were doing this as, I think, the constructor that takes an ObjectMapper is relatively new. Things may have improved by now.

[dsyer]

I masked off the ObjectMapper using a @Lazy bean to not create one until after the app had started (also had to make the EndpointMBean lazy internally), but that actually didn't improve the benchmark times. What does improve them a lot is simply excluding the actuator (independent of Thymeleaf version):

Benchmark                           Mode  Cnt  Score   Error  Units
PetclinicBenchmark.devtoolsRestart  avgt   10  0.947 ± 0.020   s/op
PetclinicBenchmark.explodedJarMain  avgt   10  2.970 ± 0.048   s/op
PetclinicBenchmark.fatJar           avgt   10  4.137 ± 0.073   s/op
PetclinicBenchmark.noverify         avgt   10  3.620 ± 0.108   s/op

I.e. #7578 is probably more interesting that tracking down Jackson issues.

[wilkinsona]

@dsyer am I right in thinking these numbers are Petclinic without Actuator and without Jackson:

Benchmark                           Mode  Cnt  Score   Error  Units
PetclinicBenchmark.devtoolsRestart  avgt   10  0.851 ± 0.018   s/op
PetclinicBenchmark.explodedJarMain  avgt   10  2.823 ± 0.075   s/op
PetclinicBenchmark.fatJar           avgt   10  3.895 ± 0.039   s/op
PetclinicBenchmark.noverify         avgt   10  3.397 ± 0.060   s/op

And the numbers are Petclinic without Actuator and with Jackson:

Benchmark                           Mode  Cnt  Score   Error  Units
PetclinicBenchmark.devtoolsRestart  avgt   10  0.947 ± 0.020   s/op
PetclinicBenchmark.explodedJarMain  avgt   10  2.970 ± 0.048   s/op
PetclinicBenchmark.fatJar           avgt   10  4.137 ± 0.073   s/op
PetclinicBenchmark.noverify         avgt   10  3.620 ± 0.108   s/op

So the cost of Jackson is ~0.1s to ~0.3s depending on the benchmark?

[dsyer]

Yes, I think that's about right. I would say we can infer that Jackson on its own is worth, by eye, about 150+/-100ms (so not completely negligible).

[lucasoares]

Hello team.. This will be prioritize anytime soon?

With lazy initialization and spring-context-indexer my application starts in 19 seconds locally and 32 seconds on Kubernetes using latest spring boot version.

I think the priority number 1 of Spring should be performance right now.

[wilkinsona]

@lucasoares Performance is an ongoing priority for the team but, without knowing more about your application and its beans, it's impossible to do much specifically for you. From what you've said, we have no way of knowing if you're using Jackson or how much of your 19 second startup time its initialization is responsible for. In short, it's not clear that prioritising this issue over other work would make a meaningful difference to your app.

The new in 2.4 startup tracking feature may be of interest as it will allow you to gather some data about where the time is being spent during your application's startup.

[philwebb]

We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.