JawnFacade
and pick a solution of using java.util.LinkedHashMap
instead of scala.collection.mutable.HashMap
that was shamelessly copied from Circe. To reproduce, please, clone jsoniter-scala repo, checkout the jawn-ast
branch and run the following command: sbt -no-colors 'jsoniter-scala-benchmark/jmh:run -i 1 -wi 1 -p size=1,10,100,1000,10000,100000 ExtractFieldsReading.jawn'
[info] REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
[info] why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
[info] experiments, perform baseline and negative tests that provide experimental control, make sure
[info] the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
[info] Do not assume the numbers tell you what you want them to tell.
[info] Benchmark (size) Mode Cnt Score Error Units
[info] ExtractFieldsReading.jawnByteBufferParser 1 thrpt 1811139.569 ops/s
[info] ExtractFieldsReading.jawnByteBufferParser 10 thrpt 260677.346 ops/s
[info] ExtractFieldsReading.jawnByteBufferParser 100 thrpt 19623.857 ops/s
[info] ExtractFieldsReading.jawnByteBufferParser 1000 thrpt 301.378 ops/s
[info] ExtractFieldsReading.jawnByteBufferParser 10000 thrpt 1.608 ops/s
[info] ExtractFieldsReading.jawnByteBufferParser 100000 thrpt 0.006 ops/s
[info] ExtractFieldsReading.jawnJsoniterScala 1 thrpt 2865937.664 ops/s
[info] ExtractFieldsReading.jawnJsoniterScala 10 thrpt 330815.496 ops/s
[info] ExtractFieldsReading.jawnJsoniterScala 100 thrpt 26956.753 ops/s
[info] ExtractFieldsReading.jawnJsoniterScala 1000 thrpt 2279.925 ops/s
[info] ExtractFieldsReading.jawnJsoniterScala 10000 thrpt 203.146 ops/s
[info] ExtractFieldsReading.jawnJsoniterScala 100000 thrpt 16.296 ops/s
[info] ExtractFieldsReading.jawnStringParser 1 thrpt 2266465.614 ops/s
[info] ExtractFieldsReading.jawnStringParser 10 thrpt 358482.177 ops/s
[info] ExtractFieldsReading.jawnStringParser 100 thrpt 24793.306 ops/s
[info] ExtractFieldsReading.jawnStringParser 1000 thrpt 352.264 ops/s
[info] ExtractFieldsReading.jawnStringParser 10000 thrpt 1.630 ops/s
[info] ExtractFieldsReading.jawnStringParser 100000 thrpt 0.006 ops/s
HashMap/HashSet
) will be fixed before 1.0.0 release
Facade
interface, but in my view it doesn't serve any real purpose, it's badly named, and if we're about to commit ourselves to a long-term 1.0.0 now is the time to get rid of it.
My ultimate goal was to add SJS support to circe-fs2.
Anyway, I can add bounds checks to get around this problem (only when running in JS) but I only want to do this where the caller doesn’t already do bounds checks.
However, I’m seeing a couple cases where the caller indicates it does bounds checks but is still failing. For example, parseNumSlow is supposedly slower than parseNum because it does bounds checks. Yet I’m seeing failures in JS where that doesn’t appear to be true. For example, one of the tests tries to access index 5 in string “1.1e+”. Is this expected?