msgpack / msgpack-ruby Public
master
Commits on Feb 9, 2022
-
Merge pull request #254 from Shopify/double-zero
Avoid zeroing msgpack_unpacker_t twice
-
Merge pull request #245 from Shopify/perf-singleton-class
Avoid creating singleton classes when looking up extensions
Commits on Feb 8, 2022
-
Avoid zeroing msgpack_unpacker_t twice
It's already zero-ed by `ZALLOC`, no need to call `memset(0, ...)` again.
-
Avoid creating singleton classes when looking up extensions
`rb_singleton_class(VALUE)` creates the singleton class if it doesn't exist yet, which isn't good for perf. First because it allocates and object, but also because as far as I know it bust method caches. Instead we can use `rb_class_of` which returns the singleton class if the object has one, or the real class if it doesn't. Later when we call `rb_obj_class`, we can compare the previous class we got, if it's different it means the object had a singleton class.
-
Merge pull request #250 from Shopify/perf-factory-packer
Packer_initialize: lazily allocate the extension and cache hashes
-
Packer_initialize: lazily allocate the extension and cache hashes
Each packer eagerly allocate two hashes, one for it's extension registry another to act as a cache for lookup and it's expensive. Assuming no extension type is used, we can significantly speedup the packer instantiation by skipping these two allocations. And in case extension types are used, we can still delay the cache allocation until it is actually needed. benchmark (`Object.new` is used as a comparison point): ```ruby require "benchmark/ips" require "msgpack" FACTORY = MessagePack::Factory.new Benchmark.ips do |x| x.report("Object.new") { Object.new } x.report("FACTORY.packer") { FACTORY.packer } x.compare! end ``` before: ``` Calculating ------------------------------------- Object.new 8.512M (± 0.7%) i/s - 42.709M in 5.017901s FACTORY.packer 1.932M (± 0.8%) i/s - 9.697M in 5.019840s Comparison: Object.new: 8511619.9 i/s FACTORY.packer: 1931874.0 i/s - 4.41x (± 0.00) slower ``` after: ``` Calculating ------------------------------------- Object.new 8.484M (± 1.7%) i/s - 42.680M in 5.032470s FACTORY.packer 3.399M (± 1.7%) i/s - 17.159M in 5.049362s Comparison: Object.new: 8483734.5 i/s FACTORY.packer: 3399232.3 i/s - 2.50x (± 0.00) slower ``` -
Merge pull request #246 from Shopify/symbolize-keys-fix-encoding
Fix `symbolize_keys: true` to properly create UTF-8 symbols
-
Fix
symbolize_keys: trueto properly create UTF-8 symbolsWhen `symbolize_keys: true` was set, we'd already read the string as binary, even if the native type is UTF-8. This was causing non-ASCII keys to be improperly deserialized. `rb_str_intern` will still notice strings that are ASCII only, and return ASCII symbol for them. So there's no backward compatibility concerns.
-
Merge pull request #247 from paarthmadan/pm/doc-typos
[Documentation]: Fix small typos
-
Merge pull request #252 from Shopify/fix-compilation-warnings
Fix all compilation warnings
-
Merge pull request #251 from Shopify/clean-jruby-checks
Clean JRuby detection in test suite
-
Merge pull request #249 from Shopify/perf-factory-unpacker
Optimize `MessagePack_Buffer_set_options`
-
-
Clean JRuby detection in test suite
IS_JRUBY was defined in `timestamp_spec` but also used in `factory_spec`. So running `factory_spec` alone would fail.
Commits on Feb 4, 2022
-
Optimize MessagePack_Buffer_set_options
`rb_respond_to` isn't very fast, so in the common case when `io` is `nil`, we can take a shortcut. On my machine while profiling `Factory#unpacker` in a loop, these `respond_to?` calls were accounting for 20% of `Unpacker_initialize`. After the change it's mostly gone.
Commits on Jan 28, 2022
Commits on Jan 22, 2022
-
Merge pull request #241 from msgpack/hotfix-for-older-java-platforms
Specify Java platform runtime as 8 explicitly
-
-
-
Merge pull request #242 from olleolleolle/patch-1
Drop unused directives from gemspec
-
Drop unused directives from gemspec
test_files is not used by RubyGems.org.
Commits on Jan 20, 2022
-
Merge pull request #238 from olleolleolle/patch-1
CI: use bundler-cache: true
-
-
Merge pull request #235 from msgpack/raise-exception-when-optimized-s…
…ymbols-unpacker-not-supported Raise exception when optimized symbols unpacker not supported
-
-
Merge pull request #236 from msgpack/update-ruby-runtimes-202201
Add Ruby 3.1 on CI
-
-
Commits on Oct 13, 2021
-
Merge pull request #225 from Shopify/optimize-sym-parsing
Optimized symbol parsing
Commits on Oct 12, 2021
-
In our app we parse a lot of msgpack payloads containing symbols, and as a result `String#to_sym` called by MessagePack is one of our biggest hotspots, so we would like to optimize it. If we add special handling for symbol parsing we can do it twice faster. ```ruby require "benchmark/ips" require "msgpack" optimized_factory = MessagePack::Factory.new optimized_factory.register_type(0x00, Symbol, packer: :to_msgpack_ext, unpacker: :from_msgpack_ext, optimized_symbols_parsing: true) MessagePack::DefaultFactory.register_type(0x00, Symbol) raise "BUG" unless MessagePack.load(MessagePack.dump(:foo)) == :foo raise "BUG" unless optimized_factory.load(MessagePack.dump(:foo)) == :foo PAYLOAD = MessagePack.dump(20.times.map { |i| :"foo#{i}" }) regular_unpacker = MessagePack::DefaultFactory.unpacker optimized_unpacker = optimized_factory.unpacker Benchmark.ips do |x| x.report('regular') do regular_unpacker.feed(PAYLOAD).full_unpack end x.report('optimized') do optimized_unpacker.feed(PAYLOAD).full_unpack end x.compare! end ``` ```bash Warming up -------------------------------------- regular 4.342k i/100ms optimized 9.156k i/100ms Calculating ------------------------------------- regular 43.592k (± 1.2%) i/s - 221.442k in 5.080628s optimized 92.098k (± 1.0%) i/s - 466.956k in 5.070682s Comparison: optimized: 92098.2 i/s regular: 43592.3 i/s - 2.11x (± 0.00) slower ```