You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*Limit document size (skip end of document when max size is reached)
27
+
* Remove whitespace
28
28
29
-
The library contains multiple filter implementations as to accommodate combinations of the above features with as little overhead as possible.
29
+
The library contains multiple filter implementations as to accommodate combinations of the above features with as little overhead as possible.
30
30
31
31
The equivalent filters are also implemented using [Jackson]:
32
32
@@ -176,15 +176,15 @@ to output like
176
176
### Path syntax
177
177
A simple syntax is supported, where each path segment corresponds to a `field name`. Expressions are case-sensitive. Supported syntax:
178
178
179
-
/my/field/name
179
+
$.my.field.name
180
180
181
181
with support for wildcards;
182
182
183
-
/my/field/*
183
+
$.my.field.*
184
184
185
185
or a simple any-level field name search
186
186
187
-
//myFieldName
187
+
..myFieldName
188
188
189
189
The filters within this library support using multiple expressions at once. Note that path expressions are see through arrays.
190
190
@@ -212,14 +212,14 @@ The resulting metrics could be logged as metadata alongside the JSON payload or
212
212
## Performance
213
213
The `core` processors within this project are faster than the `Jackson`-based processors. This is expected as parser/serializer features have been traded for performance:
214
214
215
-
*`core`is something like 3x-9x as fast as `Jackson` processors, where
215
+
*`core`processors are multiple times as fast as (streaming)`Jackson` processors, where
216
216
* skipping large parts of JSON documents (prune) decreases the difference, and
217
217
* small documents increase the difference, as `Jackson` is more expensive to initialize.
218
218
* working directly on bytes is faster than working on characters for the `core` processors.
219
219
220
220
For a typical, light-weight web service, the overall system performance improvement for using the `core` filters over the `Jackson`-based filters will most likely be a few percent.
221
221
222
-
Memory use will be at 2-8 times the raw JSON byte size; depending on the invoked `JsonFilter` method (some accept string, other raw bytes or chars).
222
+
Memory use will be at most 2-8 times the raw JSON byte size; depending on the invoked `JsonFilter` method (some accept string, other raw bytes or chars).
223
223
224
224
See the benchmark results ([JDK 17](https://jmh.morethan.io/?source=https://raw.githubusercontent.com/skjolber/json-log-filter/master/benchmark/jmh/results/jmh-results-4.1.2.jdk17.json&topBar=off)) and the [JMH] module for running detailed benchmarks.
Copy file name to clipboardExpand all lines: benchmark/jmh/src/main/java/com/github/skjolber/jsonfilter/jmh/AbstractSingleFullPathMaxStringLengthFilterBenchmark.java
0 commit comments