MessagePack for Ruby version 5
MessagePack for Ruby version 5 MessagePack for Ruby の新版をリリースしました！ さらなる高速化 APIの追加 新しいAPIリファレンス さらなる高速化 すべてのコードをゼロから再設計し、 シリアライズの大幅な高速化 を達成しました。 ruby-serializers を使って過去のバージョン（v4）と比較したところ、Twitter, 画像, 整数列, 地理データ, 3Dモデル のすべてのデータセットで高速化しました。 Twitter - 複雑なHash Twitter APIで返されるJSONを使ったベンチマークテストの結果です。 msgpack(old)（v4）と比べ、シリアライズが4倍以上高速化しました。 msgpack-ruby v5では、典型的な用途ではシリアライズ結果は数KB以下に収まる点に着目し、4KBの固定長メモリプールを導
Protocol Buffersは遅いのか - Qiita
はじめに Protocol Buffers でググると「Protocol Buffersは遅い」という記事が上位にヒットし、（記事公開から7年以上立っている現在でも）これをもって「Protocol Buffers は遅くて非効率」という印象を持たれることが多いようです。 しかし、この記事のベンチマーク実装は Protocol Buffers の性能特性を十分に活かしきれておらず、不公平な比較となっているように思われます。この記事では Protocol Buffers 寄りの視点で Protocol Buffers と MessagePack 比較を試みます。 で、遅いんですか？ わかりません。遅いんじゃないでしょうか？（！） 今回はシリアライズ速度の比較は行いません。計測がめんどくさいのと、私は ScalaPB を使っているので C++ 実装のシリアライズ速度にあまり興味がないためです。
neue cc - C#(.NET, .NET Core, Unity, Xamarin)用の新しい高速なMessagePack実装
と、いうものを作りました。MessagePackのC#版です。以前に作ったZeroFormatterのコードをベースに、バイナリの読み書きをMsgPackのフォーマットに差し替えたものになります。MsgPackのライブラリはすでにあるじゃん(MsgPack-Cli)！ってことなんですが、パフォーマンスにかなり差があります。 neuecc/MessagePack-CSharp JSON.NET（スタンダードで、豊富なAPIを持ってる）に対するJil（スピード特化、APIは必要十分はあるけれどJSON.NETほどではない）のようなものと思ってください。とはいえ、生のまま使っても問題は出ない（デフォルトのままで最高速が出るようにチューニングしてある）でしょうし、カスタマイズの口自体も十分用意してあります！詳しくは「拡張」の項で説明しますが、既に私自身が他のライブラリへの対応・インメモリデータベー
Protocol Buffers が本当に遅いのか実際に確かめてみた - @nojima's blog
Protocol Buffers で検索すると Protocol Buffersは遅い という MessagePack 作者による2008年の記事が未だに上位に来る。 一方で、Protocol Buffersは遅いのか という反論記事も見つかる。 一体遅いのか速いのかどっちなんだ！！ということで、ベンチマークを取ってみた。 2016年8月現在では、Protocol Buffer の最新バージョンは 3.0.0 であり、MessagePack の C++ バインディングの最新バージョンは 2.0.0 なので、これらのバージョンを使ってベンチマークを取ることにした。 ベンチマーク 元の記事を踏襲して、以下の４つのメッセージを使ってベンチマークを行った。 Test1: 2つの符号無し整数 Test2: 2つの符号付き整数 Test3: 8KBのバイト列 Test4: Test1 + Test2
MessagePack-RPCのプロトコル仕様（ドラフト）と実装例 - Blog by Sadayuki Furuhashi
以前に書いた MessagePack RPC プロトコル は少し古くなってしまったので、ここでまとめ直しておこうと思います。 MessagePack-RPCのプロトコルは、非同期型の呼び出しができる点（非同期プロトコル）が大きな特徴となっています。複数のサーバが相互に通信し合ったり、通信と計算をオーバーラップさせて高速化を図ったりするような、高度なネットワークアプリケーションを実装しやすくなります。 RPCライブラリと言うよりも、シンプルな非同期メッセージングライブラリと言えます。 ここではMessagePack-RPCのプロトコル仕様と、以上の特徴を活かせるような実装例も合わせて紹介します。 基本仕様：MessagePack-RPC specification version 0.1 MessagePack-RPCのプロトコルは、メソッドの呼び出すRequestメッセージと、それに対する
Go の msgpack ライブラリ比較 - Qiita
Go で msgpack を扱うには github.com/ugorji/go/codec を使っているのですが、最近 github.com/vmihailenco/msgpack を見つけてちょっとよさそうだったのでベンチマークを取ってみました。 コード package main import ( "bytes" "os" "testing" "time" "github.com/ugorji/go/codec" "github.com/vmihailenco/msgpack" ) type Event struct { Tag string `codec:"tag" msgpack:"tag"` Time time.Time `codec:"time" msgpack:"time"` Record map[string]interface{} } var ( mh = &codec.M
MessagePackの整数型のバリエーションとC#でそれに対応する型 - Qiita
require 'msgpack' numbers = [ 0, 127, 128, 255, 256, 65535, 65536, 4294967295, 4294967296, 18446744073709551615, -1, -32, -33, -128, -129, -32768, -32769, -2147483648, -2147483649, -9223372036854775808 ] numbers.each do |num| puts "#{num} => #{MessagePack.dump(num).unpack('H*')}" end 0 => ["00"] 127 => ["f7"] 128 => ["cc08"] 255 => ["ccff"] 256 => ["dc1000"] 65535 => ["dcffff"] 65536 => ["ec001000
ruby 2.0.0-p195 + fluentd v0.10.35 + msgpack v0.5.5 の組合せが素敵という話 - たごもりすメモ
fluentd v0.10.35 が出ましたね！ https://rubygems.org/gems/fluentd で、端的に申し上げまして fluentd をお使いの皆様は以下の組合せで使うのがおススメです。 Ruby 2.0.0-p195 Fluentd v0.10.35 MessagePack v0.5.5 なぜかというと以下のようなすばらしい利点があるからですね。 Ruby 2.0.0 でfluentdを走らせると大変高速 2.0.0 は each とかを回すときに非常に高速になるような改良が入っている 1.9.3 向けには funny-falcon patch として知られていたもの rvm を使ってビルドしていたrubyだと知らずに当たってるかも これが大量のメッセージに対してループが回りつづけるFluentdに超ハマる 手元計測で生の 1.9.3 の倍ちょっと高速 Ruby
Fluentd w/ Ruby 2.0.0-p0 のメモリ使用量 (追記: w/ msgpack v0.5.4) - tagomorisのメモ置き場
いくつかFluentdのベンチマークをとらないとなー、そういえばRuby 2.0.0-p0も出ましたね、ということでベンチマーク取ろうと思ってあれこれ作業してたらなんか変なのを見付けたのでとりあえず記録。 なおベンチマークの結果については、いろいろ取りかたを考え直す必要があるのでまたこんど。 概要 Fluentd の動作環境が Ruby 2.0.0-p0 with jemalloc なケースで Ruby 1.9.3-p392 に較べて大幅に大幅にメモリを食う上、負荷を停止した時にも何かよくわからない挙動を示す。 jemalloc を使わないケースだと 1.9.3 とほとんど変わらないと思われる挙動で jemalloc の必要性が無くなったとかいうわけではない。 詳細 ベンチマークは あるサーバ(4core HT, 16GB RAM)に立てた Fluentd に対し、別のサーバ(同一サブネッ
MessagePackのIETFへの提案に関する困惑 - たごもりすメモ
MessagePackというオープンソースプロジェクトの現状と IETF による標準化について、それが果たして正しいのか、と困惑せざるをえない事態が起きているので、それについて簡単に書く。何が起きているのか知らない人々に少しでも知ってもらえたら嬉しい。 なお、自分はMessagePackのユーザであって開発者ではない。MessagePackを使ったコードを書いて動かしているが、MessagePackそのもののデータフォーマットについて詳細まで知っているわけではないし、MessagePackの改善については特にいいアイデアを出せる気もしない。 現バージョンのMessagePackについてとりたてて不満はなかったが、最近文字列型を加えよう、あるいはもっと楽に文字列を扱えるようにしよう、という話が出てきた。JSON的に楽に扱えて更にバイナリデータを投入できるフォーマットの需要そのものは理解できる
MessagePack should be developed in an open process · Issue #129 · msgpack/msgpack
MessagePack has become highly visible on the Internet approximately three years ago. These three years were exciting, with many new implementations coming up. In these three years, there never was any serious attempt to evolve the specification. When I made my original BinaryPack specification proposal ("-00") in October 2012, I tried to engage @frsyuki. After a little interaction it seemed to me
Geekなぺーじ:MessagePackがIETF標準化に巻き込まれてる件について
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
MessagePack for Ruby version 5
MessagePack for Ruby version 5 MessagePack for Ruby の新版をリリースしました！ さらなる高速化 APIの追加 新しいAPIリファレンス さらなる高速化 すべてのコードをゼロから再設計し、 シリアライズの大幅な高速化 を達成しました。 ruby-serializers を使って過去のバージョン（v4）と比較したところ、Twitter, 画像, 整数列, 地理データ, 3Dモデル のすべてのデータセットで高速化しました。 Twitter - 複雑なHash Twitter APIで返されるJSONを使ったベンチマークテストの結果です。 msgpack(old)（v4）と比べ、シリアライズが4倍以上高速化しました。 msgpack-ruby v5では、典型的な用途ではシリアライズ結果は数KB以下に収まる点に着目し、4KBの固定長メモリプールを導
おひろめ会：Javaにおけるデータシリアライズ手法
Treasure Dataの基本データフォーマットであるMessagePackと、msgpack-javaでの最適化について紹介します。 Organizations need to perform increasingly complex analysis on data — streaming analytics, ad-hoc querying, and predictive analytics — in order to get better customer insights and actionable business intelligence. Apache Spark has recently emerged as the framework of choice to address many of these challenges. In this session, we
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - MessagePack-CSharp/MessagePack-CSharp: Extremely Fast MessagePack Serializer for C#(.NET, .NET Core, Unity, Xamarin). / msgpack.org[C#]![GitHub - MessagePack-CSharp/MessagePack-CSharp: Extremely Fast MessagePack Serializer for C#(.NET, .NET Core, Unity, Xamarin). / msgpack.org[C#]](https://cdn-ak-scissors.b.st-hatena.com/image/square/9ca9fad3bcdb578fb9184074a5752c30e16cfb16/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2F2e14f3ab8e73acbfb52fced380c8e4ca88dcaf93a0498a36454d39529c074004%2FMessagePack-CSharp%2FMessagePack-CSharp)
Treasure Dataを支える技術 - MessagePack編
Msgpack can't differentiate between raw binary data and text strings · Issue #121 · msgpack/msgpack
MessagePackが文字列とバイナリをわけないのは問題？
Home - MessagePack - Confluence