A data serialization language for expressing clear API messages, config files, etc. .id = @uuid("..."), .time = 1710085168, .payload = Command { .do = @action("clear_chat"), .sender = "kristoff-it", .roles = ["admin", "mod"], .extra = { "agent": "Mozilla/5.0", "os": "Linux/x64", }, } Notation designed to help users grok data layoutsStructs vs mapsZiggy uses different notation for key-value pairs w
Multiple languages: Java/Python/C++/Golang/JavaScript/Rust/Scala/Kotlin/TypeScript. Zero-copy: Cross-language out-of-band serialization inspired by pickle5 and off-heap read/write. High performance: A highly-extensible JIT framework to generate serializer code at runtime in an async multi-thread way to speed serialization, providing 20-170x speed up by: reduce memory access by inlining variables i
MemoryPackという、C#に特化することで従来のシリアライザーとは比較にならないほどのパフォーマンスを発揮する新しいシリアライザーを新しく開発しました。 高速なバイナリシリアライザーである MessagePack for C# と比較しても、通常のオブジェクトでも数倍、データが最適な場合は50~100倍ほどのパフォーマンスにもなります。System.Text.Jsonとでは全く比較になりません。当初は .NET 7 限定としてリリースしましたが、現在は .NET Standard 2.1(.NET 5, 6)やUnity、そしてTypeScriptにも対応しています。 シリアライザーのパフォーマンスは「データフォーマットの仕様」と「各言語における実装」の両輪で成り立っています。例えば、一般的にはバイナリフォーマットのほうがテキストフォーマット（JSONとか）よりも有利ですが、バイナリ
こんにちは、freee会計でワークフロー機能の開発をしている @mitubaEX です。 先日 freee会計のパフォーマンスチューニングに取り組みました。本記事では、調査の流れ、改善の事例を紹介します。 問題発覚までの流れ freee では自社の経理業務に freee会計を利用しており、その中でも経費精算の機能はほぼすべての従業員が利用しています。そのため日々多くのフィードバックをもらえます。そのフィードバックの1つで、「経費精算の一覧を開くのが遅い」という報告をもらいました。幸い表示件数を指定できるので調整すれば遅くはならないのですが、一覧性が下がってしまうため有用な解決策ではありません。 そこでワークフローを開発しているチームで、このパフォーマンスイシューの調査を始めました。 調査する まず事前調査として Datadog*1 で一覧画面を表示するリクエストの処理を確認しました。 一覧
Overview of Serialization Technologies Jim Pivarski Princeton University – DIANA-HEP March 28, 2018 1 / 24 45 years of serialization formats in (and out of) HEP 1970 1980 1990 2000 2010 2020 ZEBRA (1983) YBOS (CDF r1) ZOO proposal (1994) Objectivity (c.1994‒1998) HYDRA (1973) ZBOOK (1974) BOS (1975) ROOT (1995) CWN in PAW (1989) FORTRAN C++ MonetDB (2002) C-Store (2005) Dremel (2010) Parquet (2013
Footnotes * abomonation requires a mutable backing to access data † abomonation does not support buffer mutation ‡ do not provide deserialization capabilities, but the user can write their own § supports buffer mutation, but not in the rust implementation Analysis CBOR / serde_json Unsurprisingly, these two had very similar performance because they're almost the same format. CBOR did a bit better
fumieval.hatenablog.com あれから9ヶ月…wineryのバージョン1.0をついにリリースした。 前回までのあらすじ データの保存や通信に直列化は不可欠の概念である。 binaryなどの直列化ライブラリは、レコードのフィールド名などの情報が欠けており、構造が変わると互換性を持たせることができない。 一方、JSONやCBORなどのフォーマットで愚直にフィールド名などを残すと極めて冗長になり、時間・空間効率が悪い。 コード生成が前提のProtobufなどはHaskellの既存のデータ構造との相性がよくない。 そんな現状に殴り込みをかけたのがwineryだ。値を「スキーマ」と「データ」に分割して保存することによって、冗長性を避けつつ、メタデータを保持させることができる。wineryは最強のライブラリとなりうるか…？ 特徴と特長 JSON, MessagePack, CBORな
人類は、酒と共に発展してきたと言っても過言ではない。穀物や果実などを酒に変換することにより、糖を除く栄養を保ったまま、高い保存性を持たせることができる。酒は人々の喉を潤し、時に薬として使われた。 プログラミングにおいても、終了したら消えてしまうデータを、保存性の高いバイト列に変えたい場面がよくある。そのような操作を直列化(シリアライズ)と呼び、いくつかのアプローチが存在する。 コード生成タイプ Protocol Buffers、cap'n'protoなど データの構造を記述する言語(スキーマ)から、データ構造およびシリアライザ・デシリアライザをコードごと生成する。幅広い言語で使える一方、作れる構造が限られており、定義済みの構造にも使えないので、Haskellのような言語とは相性があまりよくない。 互換性を保つ機能が充実していることが多い。 汎用フォーマットタイプ CBOR、MessageP
Two years ago I wrote an article about working with JSON in Rust. JSON (de)serialization support was then baked in the standard library. However, at that time Rust was at version 0.13 and a lot of things happened since then. Mainly, the rustc-serialize crate got pulled out of the core libraries, but kept its close relation to the rustc compiler itself. (Hence the slightly awkward name.) Meanwhile,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
