julialang 很不错，但每次执行时的内存占用太大，感觉是预编译造成。
如果可以开启一个后台专门执行预编译，程序执行时直接使用编译好的内存二进制代码，不包含预编译部分的模块，那应该好很多。
这个预编译后台常驻公用。
这几处 128M 的内存分配真的是必须的嘛？
希望能够有开发 julia 的朋友可以参与讨论。
这几处 128M 的内存分配真的是必须的嘛？
很多人问编译与二进制相关的问题，但这是julia从一开始设计时就决定的，
用编译时间和内存占用换取运行速度,
只能说改进，不能说解决，牛头维京大佬（juila创始人之一）在英文社区里回复过这类问题，链接懒得找了，大意是说：
如果非得揪着这个问题不放，那就是另一门语言了。
目前我认为最好的解决方案是PackageCompiler.jl，一句话生成预编译文件，另一句话调用，总共两句话，另外的解决方案是仿C的StaticCompile.jl和泛平台编译器BinaryBuilder.jl,但操作略麻烦些，我没用过…
我主要说的是单次执行的内存占用问题，也提出了理论可行的解决方向。
如果有 julialang 的研发人员看看，也许对改进的方向上有些提示。
PackageCompiler.jl 也用过，加入了些包后，内存占用极具增加！
那你应该去英文社区的内部设计板块，而不是中文社区的综合讨论区呀 
希望能够有开发 julia 的朋友可以参与讨论。
那就去英文社区问吧
根据我逛 Internals & Design 的经验，你去问那些内存分配的由来或许有人能回答。讨论预编译的内存占用，也会有人响应。
但大家的点一般在：首次运行的编译过程太慢了。
一般是希望尽快的运行，哪怕效率低一些、资源消耗大一些。
大概就是希望能在想快的时候尽快解释执行，想要性能的时候，进行编译。
至于资源的占用，我看见过有人抱怨 .julia 太大；内存占用相关，一般是希望看看 GC 有多少，整体的内存占用感觉关注的人不多。
所以可能你过去发帖讨论了，有人响应并讨论，但最后没人去开 pr。
julia 的整体关注点还是在速度上，资源占用目前看 2.0 前可能都不是重点。
（说起来现在 Julia 都自举不能，hello world 静态编译还是很大
因为 Julia 的可组合性，预编译没有想象中的那么有用。因为你可以很容易的扩展某个函数，然后缓存就失效了。
具体的我这一时半会找不到相关的讨论贴了。你可以自己去英文社区搜搜预编译相关的讨论。
关键词： precompile、TTFP、sysimg
3 个赞
因为看到 3 块 128M 内存的分配，觉得这处也许可以在源码中找到并合理解决。
谢谢，看起来还需要很长段时间才能够减小内存占用，暂时只有减少使用。
UP! 看看有人感兴趣没有。
julia con 2022 今年有3个 GC 相关的演讲。
进而引出了堆碎片化的问题
1 个赞
谢谢。看官方能够讨论清楚不。