In Chrome DevTools this can be measured by comparing two heap snapshots, where first doesn't have anything and second one includes a value of interest assigned to a global variable so it doesn't get GCed

Comparing two snapshots shows allocations diff

Also can be measured in node https://github.com/roman01la/js-memory-usage

there's some caveats to this approach though

depending on the data structure and the way it is operated upon, it can suffer either optimizations/deoptimizations

like this

https://github.com/nodejs/node/issues/28205

You mean different runtimes right? That’s true. I imagine numbers can be different between browser JS VMs as well

in that case, using the same runtime but changing a for loop slightly reduced memory usage by 30 to 70%

it didn't affect node 10 but did affect node 12

this was the change

https://github.com/angular/angular/pull/31638/files

for (let prop in obj) { -> for (let prop of Object.keys(obj)) {

hehe, reminded me about this talk https://www.youtube.com/watch?v=r-TLSBdHe1A

I haven't seen it, but this sounds like it's just up my alley 😄

there’s a funny moment he describes how having a shorter user name on his machine caused GCC to produce 100x faster code 😄

you know what, that doesn't surprise me at all

webpack had a similar problem around two years ago

https://github.com/webpack/webpack/issues/5992

it's similar insofar as names and paths would be concatenated indefinitely

so the longer your file paths were, the quicker you'd hit the memory limit

This is awesome. Thank you both! What I need this for is to measure the relative size as a data structure grows, so I think Roman's suggestions should suffice.

@U04V15CAJ you can generate source maps and inspect with any bundler inspector from npm

thanks! @thheller already guided me to a solution with shadow-cljs which works quite nicely

basically you just create a simple build config and run the build report normally

:builds {:sci {:target :browser :modules {:sci {:entries [sci.core]}}}}

https://shadow-cljs.github.io/docs/UsersGuide.html#_build_report

thanks!

you may need to setup an actual example use though

if the library is written "correctly" all the code will be removed as dead code otherwise

since nothing is actually used if you just import the ns

Right. Also a lot of the core functions are pulled in by the lib, but might already be used the the app otherwise, so it wouldn't be 100% on the lib

Just to get going for now, I'm getting: Can't find 'shadow.cljs.devtools.cli' as .class or .clj for lein run: please check the spelling. I've set :lein true in shadow-cljs.edn. Should I add a dep to project.clj?

yes. include the dep

the build report shows how much your code contributed

so cljs.core code is shown separately

right

thats likely the (def clojure-core ... etc which can never be removed

acceptable size though. so probably best to set up an actual example with the common uses

yeah, it was the point of def clojure-core to hold on to all those functions, because you don't know up front which ones the user is going to use in their program string. When I compile sci to an npm library (advanced compiled JS) I end up with ~350KB unzipped

is it meant for npm consumption by js clients?

@UJVKWJTGE That's certainly one of the goals: https://www.npmjs.com/package/@borkdude/sci

You can see an example of it here: https://github.com/borkdude/sci-birch

350kb is a fair bit but for nodejs consumers it's not the worst thing in the world

especially if it's a single lib

typescript, for instance, is 7mb in a single file

and TS ships several versions of the compiler, to cater for different consumers

yeah. I guess TS is just a dev dependency though

not quite

in your case you want to interpret cljs

but there are plenty of libs that want to interpret ts

like ts-node

oh, then I'm fine I guess 🙂

or that require TS to be compiled with, like Angular

I was more worried about front-end bundle size

TS is a total of 47mb on a clean install

it's about 80kb zipped

which is fine maybe, trade-off