oj 3.12.0 → 3.13.0

Sign up to get free protection for your applications and to get access to all the features.
data/ext/oj/validate.c ADDED
@@ -0,0 +1,50 @@
1
+ // Copyright (c) 2021, Peter Ohler, All rights reserved.
2
+
3
+ #include "parser.h"
4
+
5
+ static void
6
+ noop(ojParser p) {
7
+ }
8
+
9
+ static VALUE
10
+ option(ojParser p, const char *key, VALUE value) {
11
+ rb_raise(rb_eArgError, "%s is not an option for the validate delegate", key);
12
+ return Qnil;
13
+ }
14
+
15
+ static VALUE
16
+ result(ojParser p) {
17
+ return Qnil;
18
+ }
19
+
20
+ static void
21
+ dfree(ojParser p) {
22
+ }
23
+
24
+ static void
25
+ mark(ojParser p) {
26
+ }
27
+
28
+ void oj_set_parser_validator(ojParser p) {
29
+ p->ctx = NULL;
30
+ Funcs end = p->funcs + 3;
31
+
32
+ for (Funcs f = p->funcs; f < end; f++) {
33
+ f->add_null = noop;
34
+ f->add_true = noop;
35
+ f->add_false = noop;
36
+ f->add_int = noop;
37
+ f->add_float = noop;
38
+ f->add_big = noop;
39
+ f->add_str = noop;
40
+ f->open_array = noop;
41
+ f->close_array = noop;
42
+ f->open_object = noop;
43
+ f->close_object = noop;
44
+ }
45
+ p->option = option;
46
+ p->result = result;
47
+ p->free = dfree;
48
+ p->mark = mark;
49
+ p->start = noop;
50
+ }
data/ext/oj/wab.c CHANGED
@@ -10,7 +10,7 @@
10
10
  #include "dump.h"
11
11
  #include "encode.h"
12
12
  #include "err.h"
13
- #include "hash.h"
13
+ #include "intern.h"
14
14
  #include "oj.h"
15
15
  #include "parse.h"
16
16
  #include "trace.h"
@@ -233,7 +233,7 @@ static void dump_obj(VALUE obj, int depth, Out out, bool as_ok) {
233
233
  } else if (oj_bigdecimal_class == clas) {
234
234
  volatile VALUE rstr = rb_funcall(obj, oj_to_s_id, 0);
235
235
 
236
- oj_dump_raw(rb_string_value_ptr((VALUE *)&rstr), (int)RSTRING_LEN(rstr), out);
236
+ oj_dump_raw(RSTRING_PTR(rstr), (int)RSTRING_LEN(rstr), out);
237
237
  } else if (resolve_wab_uuid_class() == clas) {
238
238
  oj_dump_str(rb_funcall(obj, oj_to_s_id, 0), depth, out, false);
239
239
  } else if (resolve_uri_http_class() == clas) {
@@ -293,7 +293,7 @@ void oj_dump_wab_val(VALUE obj, int depth, Out out) {
293
293
 
294
294
  ///// load functions /////
295
295
 
296
- static VALUE oj_hash_key(Val parent) {
296
+ static VALUE calc_hash_key(ParseInfo pi, Val parent) {
297
297
  volatile VALUE rkey = parent->key_val;
298
298
 
299
299
  if (Qundef != rkey) {
@@ -302,15 +302,14 @@ static VALUE oj_hash_key(Val parent) {
302
302
 
303
303
  return rkey;
304
304
  }
305
- VALUE *slot;
306
-
307
- if (Qnil == (rkey = oj_sym_hash_get(parent->key, parent->klen, &slot))) {
308
- rkey = rb_str_new(parent->key, parent->klen);
309
- rkey = oj_encode(rkey);
310
- rkey = rb_str_intern(rkey);
311
- *slot = rkey;
312
- rb_gc_register_address(slot);
305
+ if (Yes == pi->options.cache_keys) {
306
+ rkey = oj_sym_intern(parent->key, parent->klen);
307
+ } else {
308
+ rkey = rb_str_new(parent->key, parent->klen);
309
+ rkey = oj_encode(rkey);
310
+ rkey = rb_str_intern(rkey);
313
311
  }
312
+ OBJ_FREEZE(rkey);
314
313
  return rkey;
315
314
  }
316
315
 
@@ -468,8 +467,8 @@ static VALUE cstr_to_rstr(ParseInfo pi, const char *str, size_t len) {
468
467
  return rb_funcall(wab_uuid_clas, oj_new_id, 1, rb_str_new(str, len));
469
468
  }
470
469
  if (7 < len && 0 == strncasecmp("http://", str, 7)) {
471
- int err = 0;
472
- v = rb_str_new(str, len);
470
+ int err = 0;
471
+ v = rb_str_new(str, len);
473
472
  volatile VALUE uri = rb_protect(protect_uri, v, &err);
474
473
 
475
474
  if (0 == err) {
@@ -509,7 +508,7 @@ static VALUE start_hash(ParseInfo pi) {
509
508
  static void hash_set_cstr(ParseInfo pi, Val parent, const char *str, size_t len, const char *orig) {
510
509
  volatile VALUE rval = cstr_to_rstr(pi, str, len);
511
510
 
512
- rb_hash_aset(stack_peek(&pi->stack)->val, oj_hash_key(parent), rval);
511
+ rb_hash_aset(stack_peek(&pi->stack)->val, calc_hash_key(pi, parent), rval);
513
512
  if (Yes == pi->options.trace) {
514
513
  oj_trace_parse_call("set_string", pi, __FILE__, __LINE__, rval);
515
514
  }
@@ -522,14 +521,14 @@ static void hash_set_num(ParseInfo pi, Val parent, NumInfo ni) {
522
521
  oj_set_error_at(pi, oj_parse_error_class, __FILE__, __LINE__, "not a number or other value");
523
522
  }
524
523
  rval = oj_num_as_value(ni);
525
- rb_hash_aset(stack_peek(&pi->stack)->val, oj_hash_key(parent), rval);
524
+ rb_hash_aset(stack_peek(&pi->stack)->val, calc_hash_key(pi, parent), rval);
526
525
  if (Yes == pi->options.trace) {
527
526
  oj_trace_parse_call("set_number", pi, __FILE__, __LINE__, rval);
528
527
  }
529
528
  }
530
529
 
531
530
  static void hash_set_value(ParseInfo pi, Val parent, VALUE value) {
532
- rb_hash_aset(stack_peek(&pi->stack)->val, oj_hash_key(parent), value);
531
+ rb_hash_aset(stack_peek(&pi->stack)->val, calc_hash_key(pi, parent), value);
533
532
  if (Yes == pi->options.trace) {
534
533
  oj_trace_parse_call("set_value", pi, __FILE__, __LINE__, value);
535
534
  }
data/lib/oj/mimic.rb CHANGED
@@ -23,6 +23,8 @@ module Oj
23
23
  bigdecimal_load: :auto,
24
24
  circular: false,
25
25
  class_cache: false,
26
+ cache_keys: true,
27
+ cache_str: 5,
26
28
  create_additions: false,
27
29
  create_id: "json_class",
28
30
  empty_string: false,
data/lib/oj/version.rb CHANGED
@@ -1,5 +1,5 @@
1
1
 
2
2
  module Oj
3
3
  # Current version of the module.
4
- VERSION = '3.12.0'
4
+ VERSION = '3.13.0'
5
5
  end
data/pages/Modes.md CHANGED
@@ -97,6 +97,8 @@ information.
97
97
  | :bigdecimal_as_decimal | Boolean | | | | 3 | x | x | |
98
98
  | :bigdecimal_load | Boolean | | | | | | x | |
99
99
  | :compat_bigdecimal | Boolean | | | x | | | x | |
100
+ | :cache_keys | Boolean | x | x | x | x | | x | |
101
+ | :cache_strings | Fixnum | x | x | x | x | | x | |
100
102
  | :circular | Boolean | x | x | x | x | x | x | |
101
103
  | :class_cache | Boolean | | | | | x | x | |
102
104
  | :create_additions | Boolean | | | x | x | | x | |
data/pages/Options.md CHANGED
@@ -70,13 +70,17 @@ This can also be set with `:decimal_class` when used as a load or
70
70
  parse option to match the JSON gem. In that case either `Float`,
71
71
  `BigDecimal`, or `nil` can be provided.
72
72
 
73
- ### :compat_bigdecimal [Boolean]
73
+ ### :cache_keys [Boolean]
74
74
 
75
- Determines how to load decimals when in `:compat` mode.
75
+ If true Hash keys are cached or interned. There are trade-offs with
76
+ caching keys. Large caches will use more memory and in extreme cases
77
+ (like over a million) the cache may be slower than not using
78
+ it. Repeated parsing of similar JSON docs is where cache_keys shines.
76
79
 
77
- - `true` convert all decimal numbers to BigDecimal.
80
+ ### :cache_strings [Int]
78
81
 
79
- - `false` convert all decimal numbers to Float.
82
+ Shorter strings can be cached for better performance. A limit,
83
+ cache_strings, defines the upper limit on what strings are cached.
80
84
 
81
85
  ### :circular [Boolean]
82
86
 
@@ -90,6 +94,14 @@ recreate the looped references on load.
90
94
  Cache classes for faster parsing. This option should not be used if
91
95
  dynamically modifying classes or reloading classes then don't use this.
92
96
 
97
+ ### :compat_bigdecimal [Boolean]
98
+
99
+ Determines how to load decimals when in `:compat` mode.
100
+
101
+ - `true` convert all decimal numbers to BigDecimal.
102
+
103
+ - `false` convert all decimal numbers to Float.
104
+
93
105
  ### :create_additions
94
106
 
95
107
  A flag indicating that the :create_id key, when encountered during parsing,
@@ -251,7 +263,13 @@ compatibility. Using just indent as an integer gives better performance.
251
263
 
252
264
  ### :symbol_keys [Boolean]
253
265
 
254
- Use symbols instead of strings for hash keys. :symbolize_names is an alias.
266
+ Use symbols instead of strings for hash keys.
267
+
268
+ ### :symbolize_names [Boolean]
269
+
270
+ Like :symbol_keys has keys are made into symbols but only when
271
+ mimicing the JSON gem and then only as the JSON gem honors it so
272
+ JSON.parse honors the option but JSON.load does not.
255
273
 
256
274
  ### :trace
257
275
 
data/pages/Parser.md ADDED
@@ -0,0 +1,309 @@
1
+ # How Oj Just Got Faster
2
+
3
+ The original Oj parser is a performant parser that supports several
4
+ modes. As of this writing Oj is almost 10 years old. A dinosaur by
5
+ coding standards. It was time for an upgrade. Dealing with issues over
6
+ the years it became clear that a few things could have been done
7
+ better. The new `Oj::Parser` is a response that not only attempts to
8
+ address some of the issues but also give the Oj parser a significant
9
+ boost in performance. `Oj::Parser` takes a different approach to JSON
10
+ parsing than the now legacy Oj parser. Not really a legacy parser yet
11
+ since the `Oj::Parser` is not a drop-in replacement for the JSON gem
12
+ but it is as much 3 times or more faster than the previous parser in
13
+ some modes.
14
+
15
+ ## Address Issues
16
+
17
+ There are a few features of the`Oj.load` parser that continue to be
18
+ the reason for many of the issue on the project. The most significant
19
+ area is compatibility with both Rails and the JSON gem as they battle
20
+ it out for which behavior will win out in any particular
21
+ situation. Most of the issues are on the writing or dumping side of
22
+ the JSON packages but some are present on the parsing as
23
+ well. Conversion of decimals is one area where the Rails and the JSON
24
+ gem vary. The `Oj::Parser` addresses this by allowing for completely
25
+ separate parser instances. Create a parser and configure it for the
26
+ situation and leave the others parsers on their own.
27
+
28
+ The `Oj::Parser` is mostly compatible with the JSON gem and Rails but
29
+ no claims are made that the behavior will be the same as either.
30
+
31
+ The most frequent issues that can addressed with the new parser are
32
+ around the handling of options. For `Oj.load` there is a set of
33
+ default options that can be set and the same options can be specified
34
+ for each call to parse or load. This approach as a couple of
35
+ downsides. One the defaults are shared across all calls to parse no
36
+ matter what the desire mode is. The second is that having to provide
37
+ all the options on each parse call incurs a performance penalty and is
38
+ just annoying to repeat the same set of options over may calls.
39
+
40
+ By localizing options to a specific parser instance there is never any
41
+ bleed over to other instances.
42
+
43
+ ## How
44
+
45
+ It's wonderfull to wish for a faster parser that solves all the
46
+ annoyances of the previous parser but how was it done is a much more
47
+ interesting question to answer.
48
+
49
+ At the core, the API for parsing was changed. Instead of a sinle
50
+ global parser any number of parsers can be created and each is seprate
51
+ from the others. The parser itself is able to rip through a JSON
52
+ string, stream, or file and then make calls to a delegate to process
53
+ the JSON elements according to the delegate behavior. This is similar
54
+ to the `Oj.load` parser but the new parser takes advantage of
55
+ character maps, reduced conditional branching, and calling function
56
+ pointers.
57
+
58
+ ### Options
59
+
60
+ As mentioned, one way to change the options issues was to change the
61
+ API. Instead of having a shared set of default options a separate
62
+ parser is created and configured for each use case. Options are set
63
+ with methods on the parser so no more guessing what options are
64
+ available. With options isolated to individual parsers there is no
65
+ unintended leakage to other parse use cases.
66
+
67
+ ### Structure
68
+
69
+ A relative small amount of time is spent in the actual parsing of JSON
70
+ in `Oj.load`. Most of the time is spent building the Ruby
71
+ Objects. Even cutting the parsing time in half only gives a 10%
72
+ improvement in performance but 10% is still an improvement.
73
+
74
+ The `Oj::Parser` is designed to reduce conditional branching. To do
75
+ that it uses character maps for the various states that the parser
76
+ goes through when parsing. There is no recursion as the JSON elements
77
+ are parsed. The use of a character maps for each parser state means
78
+ the parser function can and is re-entrant so partial blocks of JSON
79
+ can be parsed and the results combined.
80
+
81
+ There are no Ruby calls in the parser itself. Instead delegates are
82
+ used to implement the various behaviors of the parser which are
83
+ currently validation (validate), callbacks (SAJ), or building Ruby
84
+ objects (usual). The delegates are where all the Ruby calls and
85
+ related optimizations take place.
86
+
87
+ Considering JSON file parsing, `Oj.load_file` is able to read a file a
88
+ block at a time and the new `Oj::Parser` does the same. There was a
89
+ change in how that is done though. `Oj.load_file` sets up a reader
90
+ that must be called for each character. Basically a buffered
91
+ reader. `Oj::Parser` drops down a level and uses a re-entrant parser
92
+ that takes a block of bytes at a time so there is no call needed for
93
+ each character but rather just iterating over the block read from the
94
+ file.
95
+
96
+ Reading a block at a time also allows for an efficient second thread
97
+ to be used for reading blocks. That feature is not in the first
98
+ iteration of the `Oj::Parser` but the stage is set for it in the
99
+ future. The same approach was used successfully in
100
+ [OjC](https://github.com/ohler55/ojc) which is where the code for the
101
+ parser was taken from.
102
+
103
+ ### Delegates
104
+
105
+ There are three delegates; validate, SAJ, and usual.
106
+
107
+ #### Validate
108
+
109
+ The validate delegate is trivial in that does nothing other than let
110
+ the parser complete. There are no options for the validate
111
+ delegate. By not making any Ruby calls other than to start the parsing
112
+ the validate delegate is no surprise that the validate delegate is the
113
+ best performer.
114
+
115
+ #### SAJ (Simple API for JSON)
116
+
117
+ The SAJ delegate is compatible with the SAJ handlers used with
118
+ `Oj.saj_parse` so it needs to keep track of keys for the
119
+ callbacks. Two optimizations are used. The first is a reuseable key
120
+ stack while the second is a string cache similar to the Ruby intern
121
+ function.
122
+
123
+ When parsing a Hash (JSON object) element the key is passed to the
124
+ callback function if the SAJ handler responds to the method. The key
125
+ is also provided when closing an Array or Hash that is part of a
126
+ parent Hash. A key stack supports this.
127
+
128
+ If the option is turned on a lookup is made and previously cached key
129
+ VALUEs are used. This avoids creating the string for the key and
130
+ setting the encoding on it. The cache used is a auto expanding hash
131
+ implementation that is limited to strings less than 35 characters
132
+ which covers most keys. Larger strings use the slower string creation
133
+ approach. The use of the cache reduces object creation which save on
134
+ both memory allocation and time. It is not appropriate for one time
135
+ parsing of say all the keys in a dictionary but is ideally suited for
136
+ loading similar JSON multiple times.
137
+
138
+ #### Usual
139
+
140
+ By far the more complex of the delegates is the 'usual' delegate. The
141
+ usual delegate builds Ruby Objects when parsing JSON. It incorporates
142
+ many options for configuration and makes use of a number of
143
+ optimizations.
144
+
145
+ ##### Reduce Branching
146
+
147
+ In keeping with the goal of reducing conditional branching most of the
148
+ delegate options are implemented by changing a function pointer
149
+ according to the option selected. For example when turning on or off
150
+ `:symbol_keys` the function to calculate the key is changed so no
151
+ decision needs to be made during parsing. Using this approach option
152
+ branching happens when the option is set and not each time when
153
+ parsing.
154
+
155
+ ##### Cache
156
+
157
+ Creating Ruby Objects whether Strings, Array, or some other class is
158
+ expensive. Well expensive when running at the speeds Oj runs at. One
159
+ way to reduce Object creation is to cache those objects on the
160
+ assumption that they will most likely be used again. This is
161
+ especially true of Hash keys and Object attribute IDs. When creating
162
+ Objects from a class name in the JSON a class cache saves resolving
163
+ the string to a class each time. Of course there are times when
164
+ caching is not preferred so caching can be turned on or off with
165
+ option methods on the parser which are passed down to the delegate..
166
+
167
+ The Oj cache implementation is an auto expanding hash. When certain
168
+ limits are reached the hash is expanded and rehashed. Rehashing can
169
+ take some time as the number of items cached increases so there is
170
+ also an option to start with a larger cache size to avoid or reduce
171
+ the likelihood of a rehash.
172
+
173
+ The Oj cache has an advantage over the Ruby intern function
174
+ (`rb_intern()`) in that several steps are needed for some cached
175
+ items. As an example Object attribute IDs are created by adding an `@`
176
+ character prefix to a string and then converting to a ID. This is done
177
+ once when inserting into the cache and after that only a lookup is
178
+ needed.
179
+
180
+ ##### Bulk Insert
181
+
182
+ The Ruby functions available for C extension functions are extensive
183
+ and offer many options across the board. The bulk insert functions for
184
+ both Arrays and Hashes are much faster than appending or setting
185
+ functions that set one value at a time. The Array bulk insert is
186
+ around 15 times faster and for Hash it is about 3 times faster.
187
+
188
+ To take advantage of the bulk inserts arrays of VALUEs are
189
+ needed. With a little planning there VALUE arrays can be reused which
190
+ leads into another optimization, the use of stacks.
191
+
192
+ ##### Stacks
193
+
194
+ Parsing requires memory to keep track of values when parsing nested
195
+ JSON elements. That can be done on the call stack making use of
196
+ recursive calls or it can be done with a stack managed by the
197
+ parser. The `Oj.load` method maintains a stack for Ruby object and
198
+ builds the output as the parsing progresses.
199
+
200
+ `Oj::Parser` uses three different stacks. One stack for values, one
201
+ for keys, and one for collections (Array and Hash). By postponing the
202
+ creation of the collection elements the bulk insertions for Array and
203
+ Hash can be used. For arrays the use of a value stack and creating the
204
+ array after all elements have been identified gives a 15x improvement
205
+ in array creation.
206
+
207
+ For Hash the story is a little different. The bulk insert for Hash
208
+ alternates keys and values but there is a wrinkle to consider. Since
209
+ Ruby Object creation is triggered by the occurance of an element that
210
+ matches a creation identifier the creation of a collection is not just
211
+ for Array and Hash but also Object. Setting Object attributes uses an
212
+ ID and not a VALUE. For that reason the keys should not be created as
213
+ String or Symbol types as they would be ignored and the VALUE creation
214
+ wasted when setting Object attributes. Using the bulk insert for Hash
215
+ gives a 3x improvement for that part of the object building.
216
+
217
+ Looking at the Object creation the JSON gem expects a class method of
218
+ `#json_create(arg)`. The single argument is the Hash resulting from
219
+ the parsing assuming that the parser parsed to a Hash first. This is
220
+ less than ideal from a performance perspective so `Oj::Parser`
221
+ provides an option to take that approach or to use the much more
222
+ efficient approach of never creating the Hash but instead creating the
223
+ Object and then setting the attributes directly.
224
+
225
+ To further improve performance and reduce the amount of memory
226
+ allocations and frees the stacks are reused from one call to `#parse`
227
+ to another.
228
+
229
+ ## Results
230
+
231
+ The results are even better than expected. Running the
232
+ [perf_parser.rb](https://github.com/ohler55/oj/blob/develop/test/perf_parser.rb)
233
+ file shows the improvements. There are four comparisons all run on a
234
+ MacBook Pro with Intel processor.
235
+
236
+ ### Validation
237
+
238
+ Without a comparible parser that just validates a JSON document the
239
+ `Oj.saj_parse` callback parser with a nil handler is used for
240
+ comparison to the new `Oj::Parser.new(:validate)`. In that case the
241
+ comparison is:
242
+
243
+ ```
244
+ System time (secs) rate (ops/sec)
245
+ ------------------- ----------- --------------
246
+ Oj::Parser.validate 0.101 494369.136
247
+ Oj::Saj.none 0.205 244122.745
248
+ ```
249
+
250
+ The `Oj::Parser.new(:validate)` is **2.03** times faster!
251
+
252
+ ### Callback
253
+
254
+ Oj has two callback parsers. One is SCP and the other SAJ. Both are
255
+ similar in that a handler is provided that implements methods for
256
+ processing the various element types in a JSON document. Comparing
257
+ `Oj.saj_parse` to `Oj::Parser.new(:saj)` with a all callback methods
258
+ implemented handler gives the following raw results:
259
+
260
+ ```
261
+ System time (secs) rate (ops/sec)
262
+ -------------- ----------- --------------
263
+ Oj::Parser.saj 0.783 63836.986
264
+ Oj::Saj.all 1.182 42315.397
265
+ ```
266
+
267
+ The `Oj::Parser.new(:saj)` is **1.51** times faster.
268
+
269
+ ### Parse to Ruby primitives
270
+
271
+ Parsing to Ruby primitives and Array and Hash is possible with most
272
+ parsers including the JSON gem parser. The raw results comparing
273
+ `Oj.strict_load`, `Oj::Parser.new(:usual)`, and the JSON gem are:
274
+
275
+ ```
276
+ System time (secs) rate (ops/sec)
277
+ ---------------- ----------- --------------
278
+ Oj::Parser.usual 0.452 110544.876
279
+ Oj::strict_load 0.699 71490.257
280
+ JSON::Ext 1.009 49555.094
281
+ ```
282
+
283
+ The `Oj::Parser.new(:saj)` is **1.55** times faster than `Oj.load` and
284
+ **2.23** times faster than the JSON gem.
285
+
286
+ ### Object
287
+
288
+ Oj supports two modes for Object serialization and
289
+ deserialization. Comparing to the JSON gem compatible mode
290
+ `Oj.compat_load`, `Oj::Parser.new(:usual)`, and the JSON gem yields
291
+ the following raw results:
292
+
293
+ ```
294
+ System time (secs) rate (ops/sec)
295
+ ---------------- ----------- --------------
296
+ Oj::Parser.usual 0.071 703502.033
297
+ Oj::compat_load 0.225 221762.927
298
+ JSON::Ext 0.401 124638.859
299
+ ```
300
+
301
+ The `Oj::Parser.new(:saj)` is **3.17** times faster than
302
+ `Oj.compat_load` and **5.64** times faster than the JSON gem.
303
+
304
+ ## Summary
305
+
306
+ With a performance boost of from 1.5x to over 3x over the `Oj.load`
307
+ parser the new `Oj::Parser` is a big win in the performance arena. The
308
+ isolation of options is another feature that should make life easier
309
+ for developers.