Reduce per-element overhead in the iterative term_to_binary/binary_to_term

オープン
  • 何か問題がありますか？
#2,466 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
47/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, erlang
領域
embedded-iot, performance

調査の方向性

Start by reading PR #2316 and trace the iterative term encoder and decoder it changed; the issue does not name source files or tests. Compare flat lists, tuples, maps, and deeply nested terms with the parent commit, including stack memory use on embedded targets. Done means preserving the iterative handling of deep terms while reducing flat-term overhead and stack allocation as described.

索引モデルが issue の本文から書いたものです。

説明

#2316 made external term encoding and decoding iterative, which is the right thing to do, but it added a constant cost per element. Quick benchmark on x86-64 against the parent commit: decoding a list of 100k small integers went from 881 to 1144 µs, encoding it from 692 to 1206 µs. Tuples and maps of similar size are in the +35-50% range. Deeply nested terms got faster and small messages don't change, so nothing dramatic, but it would be nice to get it back.

Where it comes from:

  • Decoder: every leaf goes through the work stack (nil write, push, pop, marker check, two switches) instead of a single call. Worse, a wide LIST_EXT pushes all its head slots at once, so the pre-sized stack is O(elements): about 800 KB malloc'd and freed for every decode of that 100k list on 64-bit, 400 KB on 32-bit. The recursive version needed no extra memory for a flat list. On MCUs this matters more than the microseconds, that malloc can also fail where before nothing could.
  • Encoder: a list is walked once to count the elements, then each element costs about six push/pop through the continuation marker plus the tuple/map/list checks, and everything runs twice (size pass, then write pass).

What I'd do: handle leaf elements inline in both directions and only push stack entries for container children (tuple, map, non-string list). The work stack becomes O(nesting) instead of O(elements), the big malloc goes away, and the LIST_EXT length can be patched after the walk like the old code did, so the counting pass goes away too.

主要言語
Erlang
スター
2.3k
フォーク
171
平均マージ
5日 11時間
マージ済み PR（30日）
19

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

atomvm/AtomVM のほかの issue

atomvm/AtomVM の issue をすべて見る

似ている issue

Embedded & IoT の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。