| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Ruby can do this by now on her own.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Potential memory leak
|
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
|\
| |
| | |
Fix mention of C extensions in README
|
|/
|
| |
JRuby's extension is part of json now and is written in Java.
|
| |
|
| |
|
|\ |
|
| | |
|
| |\ |
|
| | |\
| | | |
| | | | |
JSON::State is not using the parameter space_before
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This option was already documented but not implemented, allows setting
the separator used before the ":" during generation.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The space_before, space, indent, object_nl and array_nl options of the
space were not covered.
|
| | |\ \
| | | | |
| | | | | |
Improve JRuby perf. by removing source of multithreaded contention
|
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |\ \
| | | | |
| | | | | |
Use the new build env on Travis.
|
| | | |/ |
|
| | |\ \
| | | |/
| | |/| |
CI with current rbx-2
|
| | |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This option was already documented but not implemented, allows setting
the separator used before the ":" during generation.
|
| | |
| | |
| | |
| | |
| | | |
The space_before, space, indent, object_nl and array_nl options of the
space were not covered.
|
| | | |
|
|/ / |
|
|\ \ |
|
| |/ |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
instance_methods
|