Lowered optimization and targetted; even applied from the caller site

From Jeff’s juliac JuliaCon talk:

Just the _init_methods in Base take up 600k!

The first line of attack, is less code, tree-shaking, as explained there. But it doesn’t rule out my idea for remaining code:

It got me thinking, a lot of code isn’t speed critical, shouldn’t be super-optimized, for speed, since it leads to larger code that’s only run once and indirectly less speed; rather for size or even no binary/machine code at all…, and that includes many (not all init) so could non-loopy code be deoptimized or even not compiled by default? This doesn’t work in general, a lot of non-loopy (or even loopy) code, like that is only run once, also e.g. constructors, though for them not really usually, since you may construct many objects, likely.

Another related issue is, e.g. JSON3.jl is a super optimized library, i.e. for parsing at runtime, but it means larger code, and slower loading speed. Something like @deoptimized using JSON3 might be a possibility (most useful for scripts), for lots of users, e.g. those only parsing small config files (I’m thinking of PythonCall/CondaPkg). An alternative might be a different JSON library not relying on Parser.jl…

But again, it could be same or different global setting for the module, but selectively changing optimization for functions, similar to @inline can now also be used at the caller site (not just locally as before).

We already can lower optimization, or basically even use --compile=min (effectively, just done differently in code locally), for whole modules, but it has to be the same opt setting applying to all of the module, last time I checked (and it’s not inherited recursively to dependencies, can be annoying, or good depending on the situation and if you’re lowering up upping the optimization).

$ julia +1.11 --compile=min

julia> @time using JSON3
  0.173349 seconds (102.92 k allocations: 6.653 MiB)
vs


$ time julia +1.11 -e 'using JSON3'

real	0m1,078s
user	0m1,175s
sys	0m0,256s


Is similar to the former possible except at runtime?

YAML is a JSON superset in the standard and note this speed (though I'm not sure the package supports JSON to, maybe only YAML, non-superset?):

julia> @time using YAML
  0.104098 seconds (44.43 k allocations: 3.129 MiB)