# Lowered optimization and targetted; even applied from the caller site

**URL:** https://discourse.julialang.org/t/lowered-optimization-and-targetted-even-applied-from-the-caller-site/119326
**Category:** Internals & Design
**Created:** [September 12, 2024, 1:40pm UTC](https://discourse.julialang.org/t/lowered-optimization-and-targetted-even-applied-from-the-caller-site/119326 "2024-09-12T13:40:04Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [September 12, 2024, 1:40pm UTC](https://discourse.julialang.org/t/lowered-optimization-and-targetted-even-applied-from-the-caller-site/119326/1 "2024-09-12T13:40:04Z")

</div>

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
$ 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)

```