README
T
Analysis
T
CallEdge
T
CallGraph
T
CallKind
T
CallSite
T
EdgeKind
T
ElementSegment
T
Export
T
FunctionBody
T
FunctionStat
T
IndirectSite
T
Instruction
- ::nameOpcode::name
- ::operandsOpcode::operands
T
Operands
T
Options
- ::at_endReader::at_end
- ::newReader::new
- ::positionReader::position
- ::read_bitsReader::read_bits
- ::read_byteReader::read_byte
- ::read_bytesReader::read_bytes
- ::read_reftypeReader::read_reftype
- ::read_signed_lebReader::read_signed_leb
- ::read_u32_lebReader::read_u32_leb
- ::read_valtypeReader::read_valtype
- ::remainingReader::remaining
- ::seekReader::seek
T
RetainedSize
T
Section
- ::from_idSectionId::from_id
- ::is_customSectionId::is_custom
- ::nameSectionId::name
T
Sections
T
TableType
T
WasmError
T
WasmModule
V
DEFAULT_TOP
V
analyze
V
build
V
collect_function_stats
V
count_imported_functions
V
decode_instruction
V
decode_instructions
V
describe_error
V
display_name
V
find_sections
V
format_report
V
function_stats
V
indirect_targets
V
module_of
V
parse_code_section
V
parse_count
V
parse_element_section
V
parse_export_section
V
parse_module
V
parse_name_section
V
parse_options
V
parse_start_section
V
parse_table_section
V
reachable_from_roots
V
render_dead_code
V
render_dot
V
render_graph
V
render_html
V
render_json
V
render_module_summary
V
render_retained
V
render_top_functions
V
retained_sizes
V
roots_of
V
same_kind
V
scan_calls
V
usage

moonsize

A Wasm size profiler for MoonBit — section breakdown, function ranking, call graph and retained-size analysis

wasm

webassembly

size

profiling

cli

Download zip

Author

BigSaltyMan

Version

0.1.0

License

MIT

Repository

github.com/BigSaltyMan/moonsize

Last updated

8 days ago

Downloads

Dependencies

moonbitlang/x0.5.5

#moonsize

A size analyzer for WebAssembly, built for MoonBit's output. It reads a .wasm file, measures every section, attributes the code section to named functions, follows the call graph, and reports what could be deleted.

The analysis model follows Twiggy: sizes are attributed to individual functions, functions are grouped by package, and reachability from the module's roots decides what is really used.

Chinese version: README.zh.md.

#Building

moon build --release
./_build/native/release/build/cmd/main/main.exe app.wasm

#Usage

moonsize <file.wasm> [--top <n>] [--retained] [--dead-code]
                     [--call-graph <path>] [--html <path>]

  --top <n>            how many functions to rank (default 10)
  --retained           what deleting each function would free
  --dead-code          functions no root can reach
  --call-graph <path>  write the call graph as .dot or .json
  --html <path>        write the charts as a self-contained HTML report

Without flags it prints the section table, the heaviest functions and the per-package roll-up. --retained and --dead-code add their sections and can be combined. --call-graph and --html each write a file instead of printing a report, so they are used on their own:

moonsize app.wasm --retained --dead-code        # the full text report
moonsize app.wasm --html report.html            # charts, opens in a browser
moonsize app.wasm --call-graph graph.dot        # for Graphviz

#Analysis

Everything below is built on one idea: a function's bytes only matter if something can call it.

#The call graph

The decoder walks every function body instruction by instruction — the full MVP instruction set, the 0xFC saturating and bulk-memory opcodes, the exception handling and tail-call opcodes MoonBit emits, and the 0xFB garbage-collection opcodes its wasm-gc backend uses. Each body contributes:

call x — a precise edge to x;
ref.func x — a reference, which counts as reachable because the function may run later as a closure;
call_indirect — a conservative edge to every function any element segment places in that table. The table's contents are not known statically, so the candidates are all of them; a missing edge would mean a missing function and a function wrongly reported dead, which is the one mistake worth avoiding here.

A function is a root if the outside world can reach it: it is exported, it is the start function, or it sits in a table. Everything reachable from those roots is live; everything else is dead.

#Retained size

SIZE is a function on its own. RETAINED is what deleting it would actually free: its own bytes plus every function that becomes unreachable with it, with DIES counting how many that is.

That set is exactly the functions the deleted one dominates — those every path from a root has to pass through. Taking the module's graph, adding a virtual root above the real ones, and computing the dominator tree gives every function's retained size in one pass. Cycles fall out of the fixpoint rather than needing a special case, and the answer is exact rather than an approximation from local predecessor counts: if two branches both call a function, deleting one branch does not free it, but deleting the point where both branches meet does.

Reading the table:

RETAINED == SIZE — the function is load-bearing only for itself. Deleting it saves its own bytes and nothing more.
RETAINED ≫ SIZE with a high DIES — a good candidate. Removing it takes a whole subtree with it.
IND — the function can be reached through a call_indirect, so removing it is only safe if no table entry and no indirect call expects it.

Both numbers are printed on purpose. SIZE says how much the compiler could win by making the function smaller; RETAINED says how much it wins by removing it, which is usually the cheaper change.

#Dead code

Anything unreachable from the roots cannot run: no export reaches it, no start function, no table entry, and no chain of calls from any of those. Its bytes are already paid for and never used, so the list is a deletion list.

MoonBit's compiler does dead-code elimination well, so a small program usually reports none — that is a finding too.

#Judging what can be deleted

Start with --dead-code. Every row there is free to remove; check that nothing outside the module calls it by name (an exported name would have made it a root, so this is already accounted for).
Then look at --retained for large RETAINED values with DIES above zero. Those are the functions whose removal cascades.
Treat IND rows with care: an indirect candidate can only be removed when the table entry and the call sites go with it.

#HTML report

--html <path> writes the same analysis as one self-contained page: no server, no build step, no network. Open the file and the four charts are there.

A worked example is checked in at examples/report.html, generated from examples/fib.wasm — a 10,645-byte MoonBit program. It is one file: the chart library is inlined, so it can be moved, emailed or opened from anywhere.

Three headline numbers. File size, the code section, and how much of the file is unreachable. The third card turns red when there is anything to delete, which is the one number most people open the report for.

Sections — a horizontal bar per section, widest first, with the share of the file in the tooltip. This is the stage-one section table, drawn. Both bar charts are sized to their row count, so every row keeps its label; a fixed-height box makes ECharts drop most of them, and the rows that survive look like headings for the unlabelled ones below.

Top 20 functions by body size — what the compiler could shrink. Body size is used rather than the encoded size so that the ranking answers "where is the code", not "where are the size prefixes".

Modules — a donut of how the code section divides between packages, as a share of the code section rather than of the file, so the slices mean "which package is responsible for the code". Slices below half a percent are rolled into a single other slice, named on hover: a slice that thin cannot carry a label, and leaving it in draws a sliver nobody can read or aim at. Labels sit inside the ring, so they never collide with the legend.

Treemap — module → function, where area is bytes. This is the one chart that shows the whole binary at once: the big cells are the functions worth looking at, and cells are drawn red when the function is unreachable.

Hovering any bar, slice or cell shows the exact bytes and percentage. Every number in the page comes from the same Analysis the text report uses, so the two cannot disagree.

The library is vendored in assets/echarts.min.js and inlined into the page. When that file is not next to the working directory — running a installed binary from elsewhere, say — the page falls back to a CDN <scriptsrc> tag instead and the command says so; that report needs a network connection to draw.

#Example output

A 10,645-byte MoonBit program (--target wasm, debug), reduced to the analysis sections:

Retained size

    #  INDEX  SIZE  RETAINED  DIES    SHARE  IND  FUNCTION
    1     47   158      5162    46    48.4%       ____moonbit__main
    2     39   301      1773    10    16.6%       int::Int::to__string_2einner
    3     37    24       887     8     8.3%       println
    4     34     9       819     5     7.6%       moonbit.println
    5     33   206       810     4     7.6%       moonbit.fprintln
    6     28    49       717     7     6.7%       moonbit.decref
    7     29   409       668     6     6.2%       moonbit.gc.free
    8     43   633       633     0     5.9%       int__to__string__dec

  DIES counts the other functions that become unreachable with this one.
  IND marks a function a call_indirect could reach.

Dead code

  0 of 47 functions are unreachable from the roots
  0 bytes (0.0% of file)

  every function is reachable

____moonbit__main retains 5,162 bytes — 48.4% of the file, 46 functions — which is what a program with a single entry point looks like: everything hangs off it. int__to__string__dec is the largest single function at 633 bytes but retains only itself, so shrinking it is a compiler problem rather than a deletion.

--call-graph graph.dot writes the same graph for Graphviz, with dead functions dashed and indirect edges dotted; --call-graph graph.json writes it with the roots, every edge and every indirect site's candidate set.

#Development

moon check --target native --deny-warn
moon test

The test suite covers the instruction table one opcode at a time — every entry carries a canonical encoding and the length the specification gives it — and pins three real MoonBit function bodies, including one whose locals use two-byte garbage-collection reference types, so a wrong immediate width fails a test instead of quietly producing a wrong call graph.

moonsize

#moonsize

#Building

#Usage

#Analysis

#The call graph

#Retained size

#Dead code

#Judging what can be deleted

#HTML report

#Example output

#Development

#Analysis

#CallEdge

#CallGraph

#CallKind

#CallSite

#EdgeKind

#ElementSegment

#Export

#FunctionBody

#FunctionStat

#IndirectSite

#Instruction

#Opcode

#Opcode::name

#Opcode::operands

#Operands

#Options

#Reader

#Reader::at_end

#Reader::new

#Reader::position

#Reader::read_bits

#Reader::read_byte

#Reader::read_bytes

#Reader::read_reftype

#Reader::read_signed_leb

#Reader::read_u32_leb

#Reader::read_valtype

#Reader::remaining

#Reader::seek

#RetainedSize

#Section

#SectionId

#SectionId::from_id

#SectionId::is_custom

#SectionId::name

#Sections

#TableType

#WasmError

#WasmModule

#DEFAULT_TOP

#analyze

#build

#collect_function_stats

#count_imported_functions

#decode_instruction

#decode_instructions

#describe_error

#display_name

#find_sections

#format_report

#function_stats

#indirect_targets

#module_of

#parse_code_section

#parse_count

#parse_element_section

#parse_export_section

#parse_module

#parse_name_section

#parse_options

#parse_start_section

#parse_table_section

#reachable_from_roots

#render_dead_code

#render_dot

#render_graph

#render_html

Analysis

CallEdge

CallGraph

CallKind

CallSite

EdgeKind

ElementSegment

Export

FunctionBody

FunctionStat

IndirectSite

Instruction

Opcode

Opcode::name

Opcode::operands

Operands

Options

Reader

Reader::at_end

Reader::new

Reader::position

Reader::read_bits

Reader::read_byte

Reader::read_bytes

Reader::read_reftype

Reader::read_signed_leb

Reader::read_u32_leb

Reader::read_valtype

Reader::remaining

Reader::seek

RetainedSize

Section

SectionId

SectionId::from_id

SectionId::is_custom

SectionId::name

Sections

TableType

WasmError

WasmModule

DEFAULT_TOP

analyze

build

collect_function_stats

count_imported_functions

decode_instruction

decode_instructions

describe_error

display_name

find_sections

format_report

function_stats

indirect_targets

module_of

parse_code_section

parse_count

parse_element_section

parse_export_section

parse_module

parse_name_section

parse_options

parse_start_section

parse_table_section

reachable_from_roots

render_dead_code

render_dot

render_graph

render_html

render_json

render_module_summary

render_retained

render_top_functions

retained_sizes

roots_of

same_kind

scan_calls

usage