Reduce per-element overhead in the iterative term_to_binary/binary_to_term

Aperta
  • Qualcosa non va?
#2,466 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
47/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, erlang
Ambito
embedded-iot, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

#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.

Lingua principale
Erlang
Stelle
2.3k
Fork
171
Merge medio
5g 11h
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di atomvm/AtomVM

Tutte le issue di atomvm/AtomVM

Issue simili

Altre issue su Embedded & IoT

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.