Appendix: Performance Benchmark

Nine servers were measured, each in a process of its own.

Spring Boot runs with its defaults: no property is set, and Tomcat, Jackson, and Thymeleaf are what the starters bring. Spider Silk runs with its defaults too, apart from the server and the template engine its arguments pick. Both servers have a pool of at most 200 platform threads, and neither uses virtual threads.

The native images of Spider Silk were built for Jetty only.

Each case is one request that gets the same answer on both frameworks.

The json-list body is 100 records of five fields each, and the two frameworks send it byte for byte the same. The json-post case sends that document as the body of a POST /items, and both frameworks read it into records and answer with their number. The /fortunes page is a table of the 12 fortunes from the TechEmpower benchmark, one of which needs HTML escaping and one of which is Japanese. The two Thymeleaf pages are the same template file and render to the same bytes. The jte page differs in its blank lines, and in leaving " and ' unescaped in text, which HTML allows. Every value a handler answers with is built once at startup, so a request measures the framework, the serializer, and the renderer, and not the data.

benchmark/run.sh drives the whole run.

Startup is timed apart from the load cases because a process started right after the previous one stopped under full load starts up to half again as slow.

The load is wrk 4.1.0 with 4 threads and 64 keep-alive connections over loopback. The server is pinned to CPUs 0 to 3, the four performance cores, and wrk to CPUs 4 to 7, the four low-power efficiency cores. Every JVM and every native image gets -Xms1g -Xmx1g. The JVM is Temurin 25 with its default collector, G1. The -native images come from GraalVM CE 25.2.4, whose only collector is the Serial GC. The -native-oracle and -native-pgo images come from Oracle GraalVM 25.4.4 with its default collector, which is also the Serial GC. Built with its defaults, Oracle GraalVM infers a profile for each method from the code with a machine-learned model. The PGO image uses the recorded profile in its place.

The reported throughput and each latency percentile are medians of the three rounds, taken separately. Across the rounds, the throughput of most cases stayed within 10% of its median. spider-silk-jetty ran 36% above its median under text in one round, and 13% above it under json-list. spring-boot ran 11% above its median under json. Among the native images, a single round ran 10% to 15% above its median in eight cases, and 11% to 12% below it in two: spring-boot-native under json and spider-silk-jetty-native under json-post. The median of three rounds sets such a round aside. No request failed in the run.

The desktop session stayed up during the run, with a terminal, Dropbox, and an idle local text-to-speech server open, which use a few percent of one CPU at rest. No web browser window was open.

Throughput is requests per second. Latency is the time wrk measured from sending a request to receiving its response, in milliseconds. CPU is the server’s own CPU time during the measurement, where 400% means four cores busy throughout.

The ratios below divide Spider Silk’s throughput by Spring Boot’s, so a value above 1 favors Spider Silk. The last three columns set the two applications' native images from the same GraalVM against each other.

Each cell below is a native image’s throughput as a share of the same application’s on the JVM, with Spider Silk on Jetty.

Oracle GraalVM’s defaults answer 0.97 to 1.60 times as many requests as GraalVM CE, and the recorded profile adds another 1.12 to 1.43 times on top of them. The PGO images also answer with lower latency than the GraalVM CE images at every percentile but one. spring-boot-native-pgo has a p99 of 9.77 ms under json-list against 32.79 ms on GraalVM CE, but under json-post its p99 of 31.50 ms is no better than GraalVM CE’s 28.53 ms, while its p50 falls from 8.87 ms to 3.63 ms.

Startup is the median of ten starts, from before the process launches to its first 200. Memory is the process’s resident set size at that moment.

The polls come about 14 ms apart, curl’s own start included, so the native images' startup times fall on that grid. Spider Silk’s PGO image answered the first poll in four of its ten starts, at 9 to 10 ms, and the second poll in the rest, at 23 to 24 ms. The PGO images hold less memory at startup: 28 MB and 51 MB against 37 MB and 73 MB on GraalVM CE.

Spring Boot’s own log reports Started SpringBootBenchmark in 0.72 seconds on the JVM and in 0.024 seconds as a GraalVM CE native image. The difference from the table is the JVM’s own startup and the time to the first answer.

Under load, a JVM process held 770 to 870 MB, most of it the 1 GiB heap that -Xms1g reserves. The native images held 55 to 351 MB, the most under json-post on spring-boot-native.

Each native image was built three times from a clean project, and each instrumented image once. The build time covers compiling the application, running Spring’s AOT processing where there is one, and running native-image. The Spider Silk modules the application depends on were already compiled and are not counted.

native-image used all eight CPUs, at a load of 6.5 to 7.1, in every build. The PGO build takes about a third less time than Oracle GraalVM’s default build, and its binary is about a quarter smaller than GraalVM CE’s. A PGO image needs the instrumented build and the profiling run first, and the instrumented image is 2.6 times the size of the GraalVM CE image. The JVM applications' dependencies come to 9.6 MB for Spider Silk and 21 MB for Spring Boot.

benchmark/json-bench measures the JSON engine with no HTTP around it, on the documents the HTTP cases send: the 100 records of json-list and the 27-byte object of json. It also measures 100 places with three numbers each that have a fraction, and 100 orders whose status is an enum, which no HTTP case sends. The same 100 records come in more forms: with nothing to escape, with Korean strings, with their keys in reverse order, with a description of 200 characters in English and in Korean, spaced out as Python’s json.dumps and a pretty printer write them, with ids of 13 and 18 digits, and with strings of no character or one. The reversed and spaced keys stand for a document that another program wrote, and the long description for prose such as a product page. It ran on 2026-10-11 on the same machine, on AC power with the performance platform profile. It measured silk-json with the changes on top of commit 11b9a13, compiled for Java 25, under JMH 1.37 with two forks of five warm-up and five measured iterations of a second each, pinned to CPUs 0 to 3, with -Xms1g -Xmx1g, on Temurin 25. Each cell is the average time per operation and the bytes allocated per operation, the latter from JMH’s gc profiler.

The generated codec writes the list in 40% of Jackson’s time and reads it in 24%, with between a third and a half of the allocation, and writes the small object in under a fifth of Jackson’s time. The hand-written writer lands between the tree and the codec: it finds each key among the keys the document has already written, where the codec copies the key from a constant. The codec reads the 10 KB document in 92% of fastjson2’s time, and writes the small object in 92% of it. fastjson2 stays ahead writing the 10 KB document, by 3%. Its lead is in writing the strings, and it is wider where no string needs an escape: 1.17 times on the plain records and 1.11 times on the Korean ones. fastjson2 reads a String’s own bytes through `sun.misc.Unsafe, which the JDK is retiring and core does not use. The codec copies a string’s characters out with getChars and checks them one at a time. Copying a string’s bytes with no check at all, a floor no correct writer can stand on, writes the plain records in 2.7 µs, ahead of fastjson2’s 3.7 µs. Checking that copy eight bytes at a time takes it to 4.0 µs, so the lead is the string’s representation, all of it. The codec escapes a quote or a backslash in the same loop that writes the plain characters, and compares each character instead of looking it up in a table. Before it did, the first quote sent the rest of the string to a slower loop, and the same write took 5.3 µs. The JIT compiler of JDK 25 does not vectorize a loop that narrows a char to a byte, so a pass that checks the whole string before writing it measured slower, not faster. The codec writes a member’s key and value with one call, put(JsonKey, …​), which checks the writer’s state once. It writes a number below 1000 with one store, and a three-byte character, such as a Korean syllable, with one four-byte store. Measured back to back with the build before them, these took the plain records from 4.4 µs to 4.2 µs and the Korean ones from 4.4 µs to 4.0 µs. On Temurin 21, which the release targeted before it required Java 25, the ratios were the same: fastjson2 writes the plain records 1.15 times as fast and the Korean ones 1.13 times, and the codec reads the list in 88% of fastjson2’s time.

A string of 64 characters or more takes another path. The JDK’s US_ASCII encoder narrows it into the buffer through an intrinsic of the JIT compiler. The string’s own indexOf, another intrinsic, finds its quotes and backslashes, and the narrowed bytes before them are checked eight at a time for a control character only. An escape moves the narrowed bytes after it up, rather than narrowing them again. The encoder stops at the first character past ASCII, and the rest of the string goes to the loop that writes one character at a time. Measured back to back with the builds before them, these took the records with a long description from 15.0 µs to 8.6 µs, and then to 6.9 µs. fastjson2 still writes them 1.08 times as fast. In Korean, the codec writes the long descriptions in 62% of fastjson2’s time. Java 25 has MemorySegment.setString, the one public call that copies a string’s Latin-1 bytes with no widening to char. Copying through it and checking the bytes eight at a time wrote the 10 KB list in 5.4 µs against 4.9 µs and the long descriptions in 7.1 µs against 6.8 µs, so the codec does not use it. The codec allocates 0.7 KB more for them, the encoder and the two buffers around it, made once per document. A plain string pays on this path from about 16 characters, on Temurin 21, on Temurin 25, and under GraalVM’s JIT compiler alike. A string with escapes pays only from 48 to 96 characters, depending on the compiler, and the threshold of 64 sits between the two. The 2% to 2.5% that this path first cost the 10 KB list no longer shows: without the path, the same build writes the list in 4.68 µs against 4.72 µs.

An enum constant is written and read through its name encoded once as a JsonKey. The name is copied out as a key is, and compared in place on the way in, with no string made. Measured back to back with the build before, this took the orders from 2.9 µs to 2.4 µs out and from 4.6 µs to 3.0 µs in, now 91% and 96% of fastjson2’s time. A generated codec does this for an enum wherever it stands: a property, an Optional, an element of a collection, or a value of a map.

The codec reads the Korean records in 72% of fastjson2’s time. It checks a string that has bytes past ASCII and decodes it into characters in the same pass, and widens the ASCII before them without a check. Before it did, it checked the bytes and then had the JDK decode them again, and the same read took 11.0 µs. fastjson2 does not check them: an overlong sequence, or a surrogate written as UTF-8, becomes U+FFFD in the value, where the codec rejects the document. A generated read tries the declared keys in order first. A key out of that order is found by a switch on the four bytes where the next member stands, which JsonInput.keyHead() reads. Measured back to back with the build before, this took the list from 6.0 µs to 5.5 µs and the reversed one from 9.5 µs to 8.0 µs. Once a document has left the declared order, each key after it goes straight to that switch, which took the reversed records to 7.2 µs. fastjson2 still reads them 1.17 times as fast. The read also passes over whitespace before a key and after its comma, and checks a comma and one space first. Measured back to back with the build before, this took the records as json.dumps spaces them from 10.0 µs to 6.6 µs, 95% of fastjson2’s time, and the indented ones from 11.6 µs to 8.6 µs. In this run the indented ones took 1.11 times fastjson2’s time. An integer of 8 to 16 digits is read two words at a time, which took the 18-digit ids from 6.5 µs to 5.9 µs. The codec reads the 13-digit and the 18-digit ids in 86% and 83% of fastjson2’s time. An empty or one-character string comes from a table with no allocation, which took the records of such strings from 3.4 µs and 13.9 KB to 2.8 µs and 5.5 KB, 73% of fastjson2’s time. fastjson2 also reads the long descriptions 1.21 times as fast. It finds the end of a string and makes the String through JDK internal methods that it binds by way of sun.misc.Unsafe, and the public API has no equivalent.

Each place has a latitude with four decimals, a longitude with six, and a rating with one. The codec reads them in 96% of fastjson2’s time with the same allocation, and in a fifth of Jackson’s. readDouble converts a number from its digits, with one multiplication or division for numbers like these. Before it did, it made a string of each number for Double.parseDouble, and the same read took 12.6 µs and 43.9 KB. Jackson 3 parses a double with its fast parser by default, so turning USE_FAST_DOUBLE_PARSER on changed nothing. The codec writes the places in 98% of fastjson2’s time with half its allocation, little more than the document itself, and in under half of Jackson’s time. JsonOutput lays out a double’s shortest decimal straight in its buffer, by the algorithm Double.toString uses since JDK 19, and writes the same text. Before it did, it made a string of each number with Double.toString and copied it, and the same write took 16.5 µs and 35.6 KB.

Written to a stream straight from the thread’s buffer, as WebResponse.json sends a body, the list takes 3.8 µs and 184 bytes. That is 1.0 µs and 10.5 KB less than the array toBytes() copies the document into. fastjson2’s JSON.writeTo saves as much, so the saving is the framework’s rather than the library’s. In the HTTP json-list case, the same change took the allocation per request from 14.4 KB to 3.8 KB on Jetty and from 13.2 KB to 2.6 KB on Tomcat, counted from the GC log over 30 seconds of load.

fastjson2’s speed comes with terms that the table does not show. Under --sun-misc-unsafe-memory-access=deny, fastjson2 2.0.57 does not initialize: JDKUtils.<clinit> fails at arrayBaseOffset, and every later call throws NoClassDefFoundError. -Dfastjson2.creator=reflect fails the same way, and fastjson2 has no mode without sun.misc.Unsafe. On JDK 24 and later, its first call prints a warning that a method of sun.misc.Unsafe will be removed in a future release. JEP 471 and JEP 498 set the order: a warning, then denial by default, then removal. The default in JDK 26 and JDK 27 is still the warning, and no JEP yet makes denial the default or removes the methods. fastjson2’s 2.1.x branch, which moves to VarHandle, has had no change since February 2026. With -Dfastjson2.creator=reflect on the JVM, fastjson2 builds no classes at run time, and reads the list in 24.5 µs and 111.2 KB, four times its usual time, and writes it in 5.7 µs. In a GraalVM native image, fastjson2 turns off its String fast path and its generated classes, and binds through reflection, which needs reachability metadata for every type it binds. fastjson2 2.0.57 does not build into a native image with the settings its jar carries, under GraalVM CE 25.2.4. Those settings initialize JSONFactory and a few other classes at build time, and the objects those classes hold reach classes the settings leave to run time, which native-image refuses. Built with the whole package initialized at build time, the image misreads the records: "available":false fails with syntax error : 102, while true reads. fastjson2 reads false through sun.misc.Unsafe, at an offset into the byte array that JDKUtils computed in the JVM that built the image. That offset is 16, and the image’s own is 12. JDKUtils is one of the classes fastjson2’s own settings initialize at build time, so the offset is wrong in any image of it that builds. silk-json reads through a VarHandle view of the array, which carries no offset.

json-bench/native-bench.sh builds six of the cases into a native image with GraalVM CE 25.2.4’s defaults, and NativeBench measures them with no JMH around them: a warm-up of three seconds, then the median of ten rounds of one second. The same harness on Temurin 25 gives the JVM column.

The native image takes 1.3 to 2.6 times the JVM’s time, as the native images of the HTTP cases answer fewer requests than their JVMs. Built with -O3, the image took 0% to 8% less time in each case, and with -march=native from 6% less to 11% more, so neither option closes the gap to the JVM. fastjson2 is left out of the table, since its image misread the documents. In the HTTP cases the serializer and the parser are a share of each request, and Reading the results sets them against the throughput.