[anilgulecha]

The author should call out size of binaries (compiled and generated), the interpreter as well since that's teh selling point. if it's tiny from memory requiremetns , shoudl also call out the same, potentially benchmarking against similar (luajit?).

[confis]

i just changed this in v0.2.7: the tiny compiler binary went from about 62 mb to about 16 mb by no longer embedding every target runtime inside the compiler. runtimes are downloaded and cached only when they are needed.

for memory, i did a quick test using tiny's built-in runtime.memoryStats(). these are go runtime heap stats rather than process rss.

at startup: about 8.1 mb alloc / 19.7 mb sys.

after keeping 100k object records alive, each with strings and nested arrays: about 109.3 mb alloc / 126.5 mb sys.

i should make these numbers easier to find in the readme/release notes instead of making people dig for them.

luajit is a useful reference point, but i don't think a direct comparison would be very meaningful right now. it is a much more mature runtime optimized in c, while tiny is still young, runs on top of go's runtime, and uses wasm as its jit backend, so the tradeoffs are pretty different.