Protobuf Codec Benchmark
Latest stable Based on Bluetape4k release 1.12.1
Problem
Section titled “Problem”This module measures the protobuf codec paths used by bluetape4k serialization and Redisson integration code. This manual connects that purpose to the current build, source entry points, tests, configuration resources, and lifecycle evidence instead of duplicating the README feature list.
When to use
Section titled “When to use”Use protobuf-codec-benchmark when the application needs the hypothesis, benchmark task, environment, metric direction, and comparison limits. Start with the source entry points below and confirm that their ownership and failure contracts match the calling component. Prefer a smaller standard-library or already-adopted module when it satisfies the same contract without another runtime boundary.
Coordinates
Section titled “Coordinates”This benchmark project is not published as a Maven artifact. Run it from the repository and inspect its Gradle tasks before choosing a command.
Gradle project path: :protobuf-codec-benchmark. Source directory: benchmark/protobuf-codec-benchmark.
Concepts
Section titled “Concepts”The module is configuration or platform metadata and has no Kotlin/Java source type to index.
Quick start
Section titled “Quick start”List the project tasks before running the example or benchmark:
./gradlew :protobuf-codec-benchmark:tasks --allThen use the command documented by the module README and keep required external services isolated.
API by task
Section titled “API by task”No Kotlin/Java source file is registered for this module. Use the build model and README as its public surface.
Patterns
Section titled “Patterns”The exact 17-cell matrix compares serializer, Redisson, and Lettuce paths. Only retained optimized candidates can make an allocation claim; baselines, compatibility controls, fallback cells, and rolled-back serializer decode cells are claim-ineligible. The committed issue #757 report contains two canonical runs. It supports the accepted Lettuce heap/direct allocation result but does not prove zero-copy or a general throughput improvement.
Integrations
Section titled “Integrations”The module build declares no direct api, implementation, compileOnly, or runtimeOnly dependency line. Inspect plugins and generated metadata in the build file.
Configuration
Section titled “Configuration”No module-level configuration resource was found under src/main/resources. Configuration is supplied through constructors, builders, function arguments, or the integrating framework; confirm defaults in source.
Failures
Section titled “Failures”Failure semantics are defined by the linked entry points and tests, not inferred from the artifact name. Keep cancellation and timeout signals intact, close owned resources, and translate backend exceptions only at a boundary that can add a stable domain contract. Use the test anchors below to verify the exact behavior before adding retries or fallbacks.
Operations
Section titled “Operations”Build one JMH JAR, pin its hash and file identity, run the canonical profile twice without rebuilding, and compare only equivalent environments. Publish only evidence accepted by the fail-closed runner and regenerate the report from its delivery manifest.
Testing
Section titled “Testing”Run the module test task:
./gradlew :protobuf-codec-benchmark:test --no-configuration-cacheNo Kotlin/Java test file was found in the manifest’s test paths. Verify the module build and add a focused contract test when adopting behavior not covered elsewhere.
Workshops
Section titled “Workshops”No dedicated workshop path is registered in the manual manifest. Use the module README and the representative tests above as runnable evidence.
Limitations
Section titled “Limitations”This page documents the repository state represented by the linked source and tests. It does not turn optional backends into application defaults or claim performance without a benchmark artifact. Re-check compatibility and lifecycle notes when the module version changes.