* ext/json/ext/generator/generator.c (cState_s_allocate): allocate structs with making new wrapper objects and get rid of potential memory leak. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@50661 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/json/ext/parser/parser.rl (cJSON_parser_s_allocate): allocate structs with making new wrapper objects and get rid of potential memory leak. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@50660 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The RuntimeInfo.forRuntime method synchronizes all invocations and ParserSession#parseString was calling this many times when parsing large JSON strings. Thus, when running in a heavily multithreaded environment, threads were spending a large portion of their time waiting on that synchronization instead of doing work parsing the JSON. This fix simply passes in the RuntimeInfo object to the ParserSession when it's instantiated, since the RuntimeInfo is already known and we've already incurred the synchronization cost at that time. Using the test script at https://gist.github.com/bbrowning/0b89580b03a5f19e7a9f, I get the following results before and after this fix on my machine: Before: $ jruby ~/tmp/json_contention.rb 337.920000 0.570000 338.490000 ( 57.955000) After: $ jruby ~/tmp/json_contention.rb 326.400000 0.580000 326.980000 ( 43.084000) That's a 25% reduction in processing time for parsing the same JSON on my quad core machine. I'd expect an even higher percentage improvement on a machine with more CPUs.
This is probably a contraversial idea. ruby-head can be fairly unstable but then json is a core gem. At least if it's an allowed-failure then builds will always be run against ruby-head, but pull requests (and master) won't report build failures if something is broken in ruby-head
The use of Hash#update from the JSON.dump method was mutating the dump_default_options hash on any call to dump with a limit provided. An individual method call with an overriding value shouldn't update the defaults in this way.
… on instance_methods