Hacker News new | ask | show | jobs
by adgjlsfhk1 1402 days ago
In the past the benchmarkgame people haven't let us use PackageCompiler. The big memory gain would be that you could skip loading things like LinearAlgebra and the other standard libraries that aren't being used (but which you are still loading code for).
1 comments

I think some more effort should be made in getting the default memory usage down to a more reasonable level. This site https://programming-language-benchmarks.vercel.app/problem/h... shows a simple Hello World Julia program as using 169 MB of memory (and I saw similar memory usage on my computer running '/usr/bin/time julia -e 'println("Hello World!")'') which was the third worse of all the programming language implementations that were tested.
Oh definitely agreed. A lot of this is because Julia always loads BLAS and LLVM, so it's like doing `import numpy; import numba; print("Hello World")` and then noticing most of the startup time is loading numpy and numba. But it's a hard question because if BLAS isn't always loaded with Julia, its previously core scientific computing case is impacted. As it has been growing to be more widely used in a general purpose case, these kinds of assumptions are having to be revisited.

One can of course remove this in the compilation stage of PackageCompiler because PackageCompiler builds a new system image, and where BLAS is loaded is in the system image, so you can create a new from-scratch system image that is more lean. However, the tooling isn't quite there yet: right now the main way that's documented is something that extends the default system image, hence the large binaries. There's StaticCompiler.jl which does tree shaking so it makes small binaries, but it doesn't support most of the Julia runtime right now so it's limited in the codes it can handle. So right now the foundation all exists and it's at a usable state but definitely needs to improve.

Absolutely! This isn't high priority but there is some very low hanging fruit. It's not that reducible though since llvm is 84 of those megs and they have to go into memory if you want to be able to generate new code.