Zig で簡単な JSON パーサを書いてみた。
#include <stdio.h> int main(int argc, char* argv[]) { int i; for (i = 1; i <= 100; i++) { if (i % 15 == 0) puts("FizzBuzz"); else if (i % 15 == 0) puts("FizzBuzz"); else if (i % 3 == 0) puts("Fizz"); else if (i % 5 == 0) puts("Buzz"); else printf("%d\n", i); } return 0; } fn main() { let mut x = 1; while x <= 100 { if x % 15 == 0 { println!("FizzBuzz"); } else if x % 3 == 0 { println!("Fizz"); } e
Nintendo Switch™ ネイティブバイナリへの Go コンパイルを成功させた話
本記事は「Go Advent Calender」25 日目の投稿です。 Happy Holidays! EDIT (2022-01-03): There is an English version of this article. tl;dr いままでは Go プログラムを Nintendo Switch 上で動かすために WebAssembly に一度変換し、それを C++ に変換してコンパイルするということを行ってきました。今回、 Go の Nintendo Switch 向けネイティブコンパイルに成功し、実際に手元でゲームを動かすことができました。手法として、システムコール呼び出しを C の関数呼び出しに置き換えるように -overlay オプションを指定してビルドしました。また、 -overlay オプションに指定する JSON を生成するパッケージ Hitsumabushi を開
grep の「バイナリファイル (標準入力) に一致しました」が出る条件を調べていたらそれは長い旅路の始まりだった。
はじめに 昨今では1行につき、1つの JSON を出力する様なログファイル形式も珍しくはありません。 grep しやすい データベース化しやすい これらの理由で各所で多く使われています。僕も仕事で普通に使っているのですが、ある日突然そのログファイルを集計するスクリプトで以下の様なエラーが出始めました。
pip 9.1 から msgpack が使われるようです - methaneのブログ
Adopt cachecontrol 0.12.0 with msgpack support というコミットがありました。 どうやら CacheControl というのが pip が使っている requests 用のキャッシュライブラリで、その最新版が msgpack を使っているようです。 前のバージョンはバイナリデータを base64 した上で json に入れて gzip していたのですが、もともと圧縮されてるバイナリを扱うときに gzip は base64 によって増えた分を減らす以上の効果は期待できない上、 PyPI からダウンロードするファイルってほぼ100%圧縮済みなので、キャッシュファイルの読み書きで無駄なオーバーヘッドがあったみたいですね。 バンドルされてる msgpack は pure Python で実行できる fallback モジュールのみなのでどこでも動くし、
PythonのJSONパーサのメモリ使用量と処理時間を比較してみる | POSTD
私は、多数の大容量のデータをあちこちに移動させなければならない(クライアント端末をHTTP APIに接続してデータを取得します)ような特殊な使用事例を扱っています。なぜだか ^(1) 、転送形式にはJSONが使われていました。ある時、その大容量のデータが、さらに巨大になったのです。数百メガバイトどころではありません。JSONのデコード処理を実行すると大量のRAMが使用されることが分かりました。たった240MBのJSONペイロードで4.4GBですよ。信じられません。 ^(2) 組み込みのJSONライブラリを使っていて、まず「もっと性能の良いJSONパーサがあるはずだ」と思いました。そんなわけで、計測を始めたのです。 さて、メモリ使用量の計測はやっかいです。 ps コマンドを使ったり、 /proc/<pid> を見たりすることはできますが、断片的なスナップショットが得られるだけで、実際の最大使
Hashicorp Ottoを読む
Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる． バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと． なぜOttoか? なぜVagrantで
PostgreSQL 9.4がリリース。ドキュメントDB並の性能でJSONBサポート、レプリケーション機能の高度化など
PostgreSQL 9.4がリリース。ドキュメントDB並の性能でJSONBサポート、レプリケーション機能の高度化など PostgreSQL 9.4の主な新機能は、バイナリ形式のJSONであるJSONBのサポート、高度なレプリケーションに利用できる新しいAPI、GINインデックスの高速化など。 一般的なドキュメントデータベース並の高速性 PostgreSQLでは以前のバージョンからJSON形式をサポートしていましたが、今回サポートされたJSONB形式は、バイナリ形式のJSONデータへの対応です。JSOBのサポートGINインデックスの高速化によって、ドキュメントデータベース並みの高速性を実現したとのこと。 JSONB supports fast lookups and simple expression search queries using Generalized Inverted In
バイナリシリアライズ形式「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ページを開く
MessagePackが文字列とバイナリをわけないのは問題？