Replace Jackson library by simple data I/O streams

[JaroslavTulach]

Pull Request Description

Improving #8553 by using DataOutputStream and DataInputStream instead of complex JSON serialization and deserialization.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Java,
  style guides.
• All code has been tested:
  • Unit tests continue to pass
  • Remove Jackson from suggestion DB cache - done
  • Remove Jackson from import/export cache - done.
  • Benchmarks look better: first fix
  • Benchmarks look even better with three fixes

[Akirathan]

Do you plan to also get rid of the JSON Object mapper in

enso/engine/runtime/src/main/java/org/enso/interpreter/caches/ImportExportCache.java

Line 183 in c109886

private static final ObjectMapper objectMapper = new ObjectMapper();

and in

enso/engine/runtime/src/main/java/org/enso/interpreter/caches/SuggestionsCache.java

Line 30 in c109886

private static final ObjectMapper objectMapper = new ObjectMapper();

?

These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

[hubertp]

Do you plan to also get rid of the JSON Object mapper in
...
These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

That could be nice, since their initialization is pretty expensive, even if done only once.

[JaroslavTulach]

Looks like elimination of Jackson is a way to go. The startup decreased from 2940ms to 2780ms - e.g. 5% speedup:

[JaroslavTulach]

Do you plan to also get rid of the JSON Object mapper in

enso/engine/runtime/src/main/java/org/enso/interpreter/caches/ImportExportCache.java

Line 183 in c109886

private static final ObjectMapper objectMapper = new ObjectMapper();

and in

enso/engine/runtime/src/main/java/org/enso/interpreter/caches/SuggestionsCache.java

Line 30 in c109886

private static final ObjectMapper objectMapper = new ObjectMapper();

?

Yes, let's do it! I've just added two tasks into this PR and I will do that by Monday.

These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

That would be great achievement! The less dependencies, the better.

Do you plan to also get rid of the JSON Object mapper in
...
These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

That could be nice, since their initialization is pretty expensive, even if done only once.

The only alternative is to switch to annotation processor based analysis like micronaut serde and eliminate the expensive initialization during runtime.

However, given how easy it is to use DataOutputStream for our purposes, we should really get of the JSON altogether.

[JaroslavTulach]

The final results of last week speedups are visible in graph generated by:

enso/tools/performance/engine-benchmarks$ ./bench_download.py -s stdlib -b develop wip/jtulach/AvoidJacksonOnstartup_8553

On Jan 2 the Startup_empty_startup benchmark was running in 3218ms. On Jan 8 it runs in 2794ms. Result of:

• Test benchmark theory #8668
• Remove org.bouncycastle dependency #8664
• Cats are not welcome #8696
• Using simple data I/O streams instead of Jackson in ModuleCache

E.g. 13% speedup, congrats @Akirathan, @hubertp!

[Akirathan]

Looks very nice. I also like the fact that the *.meta files in IR caches are still readable from a text editor.

[JaroslavTulach]

To eliminate compile time dependency on Jackson isn't really easy. There is polyglot-api project which depends on Jackson. I've just created a branch wip/jtulach/NoCompileTimeJackson that shows a possible approach to eliminate such dependency:

• splits polyglot-api project into two and creates engine-common
• moves suggestions handling into runtime-suggestions project

The remaining problem is SerializationManager it needs access to suggestions, but it is also required to be in the runtime. Not sure how to solve this problem yet. As such I just report the status here, without attempting to move it forward right now.