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!
Comment From: 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.
Comment From: 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.
Comment From: 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?
Comment From: 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).
Comment From: 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.
Comment From: 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.
Comment From: 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.