For comparison 1.13 takes 1.08 GB
$ $ du -hs julia-*
314M julia-1.0.5+0.x64.linux.gnu
609M julia-1.10.11+0.x64.linux.gnu
996M julia-1.11.9+0.x64.linux.gnu
1.1G julia-1.12.6+0.x64.linux.gnu
700M julia-1.12.6+0.x86.linux.gnu
1.1G julia-1.13.0-rc1+0.x64.linux.gnu
425M julia-1.7.3+0.x64.linux.gnu
452M julia-1.8.5+0.x64.linux.gnu
500M julia-1.9.4+0.x64.linux.gnu
1.2G julia-nightly
Found out why. The Win installer is shipping the .dylib libs too.
Sounds like a bug - hopefully won’t be too hard to fix. No sense in shipping macOS libraries on Windows. Is there an open GitHub issue for this?
Situation is fixed now.
Thanks.
Unfortunately it now takes 2.23 GB and no *.dylib now. share\julia\compiled alone takes 470 MB ???
I Have no permissions to reopen the issue.
Good thing you found and reported the dylib issue then! 
I’ve not been following the recent dev work closely enough to know if this one was an intentional tradeoff or a known transient situation or an unintentional regression. That’s kinda part of using -nightly, really. You could open a new issue I suppose, but remember that you are using the unsupported nightly build.
Well, yes I can open a new one (and will) but why are original issue authors are not allowed to reopen their issues?
And, sorry, what do you mean by unsupported nightly build?
Well, you can always ask for an issue to be reopened, but in this case I’d say the restriction worked as intended. Since the problem is no longer the dylibs it’s (potentially) a new issue.
And, yeah, nightlies are:
intended as developer previews into the latest work and are not intended for normal use. Most users are advised to use the current stable release version of Julia.
Maybe unsupported isn’t quite the right word, but my point is that they’re not real releases or even release candidates. They have both known and unknown issues. Before I go reporting something against nightly, I try to dig a bit to see if I can identify what changed and if it was intentional. And that’s where this stands in contrast to a release or release candidate: nightlies are developer products and so it’s nice to do some of that dev legwork before filing issues.
I know nightlies are not for normal usage. But from time to time I like to see if my stuff has not new problems and mainly, with the more and more vague hope that latencies will start to reduce instead of keeping increasing (compile time. loading time, …)
I think it’s worth opening a new issue. The code in Julia nightly will eventually become the starting point for the next Julia 1.x release, so I think it’s reasonable to keep an eye on it for regressions.
I think a new issue makes more sense than reopening the existing issue, because IIRC the existing issue was about shipping the macOS dylibs on Windows (which IIUC has been fixed).
Well, actually the other issue was about suspiciously large file usage, like the current report. It happens that after having raised it I found the reason and added to to the issue (see historical of this thread).
My suspicion is that this might be the new objcache. I noticed it in the release artifacts earlier, but haven’t had the time to look into yet (objcache has a few other high priority items that need addressing).
Can’t spin up a bot these days to do some investigating?
All the bots I can afford are currently busy.
I am (temporarily) not making use of my tokens if someone wants to give me something I can /goal and tab out from