JuliaPhysics / JuliaPhysics/Unitful.jl

Units interface package

Open
#595 28 comments 1 reaction 0 assignees View on GitHub
Dominant language
Julia
Stars
675
Forks
124
Avg merge
3h 38m
Merged PRs (30d)
1

Description

`using Unitful` currently takes 1 to 3 seconds[^timing].

This is fine if you're planning on actually using physical units in your Julia session.[^precompile]
But it adds to the load time of downstream packages that offer _optional_ Unitful support.

My concrete motivation for writing this issue is that I want to add Unitful support to Distributions.jl:
- https://github.com/JuliaStats/Distributions.jl/issues/1413#issuecomment-1301249731

Doing that would require adding Unitful as a dependency to Distributions. But most Distributions.jl users will not use the new unitful distributions; and they would still get the added start-up latency.

That is why I propose to create a very **lightweight package that defines just the interface/API** for working with units in Julia. Something like `UnitfulCore`, or `UnitsInterface.jl`.

Downstream packages offering physical unit support would then load just that interface package.
(If the user wants to actually _use_ the unit support, they have to explicitly be `using Unitful, DownstreamPkg`).

This pattern has been applied before, e.g. in StaticArrays.jl. From [its readme](https://github.com/JuliaArrays/StaticArrays.jl):
> Most of the primary array types exported by StaticArrays.jl are defined in the small interface package [StaticArraysCore.jl](https://github.com/JuliaArrays/StaticArraysCore.jl). This includes e.g., the definitions of the abstract type `StaticArray` and the concrete types `SArray`, `MArray`, and `SizedArray` (as well as their dimension-specific aliases). This enables downstream packages to implement new methods for these types without depending on (and hence loading) the entirety of StaticArrays.jl, and thereby to avoid incurring the full load-time of StaticArrays.jl (which is on the order of 0.6 s for StaticArrays.jl v1.4 on Julia v1.7).

---

So my question to the maintainers of Unitful.jl is: would you be open to adding such an interface package as a dependency of Unitful, and moving some core types and functions to that package (or having them subtype from the package) ?




[^timing]: `@time using Unitful` gives 1.0 seconds [on replit][replit], and between 1.6 and 2.6 seconds on my laptop (Julia 1.8).
[^precompile]: Though a [`@precompile_all_calls`][snoop] block might be a good idea to add to src/ in any case.

[snoop]: https://timholy.github.io/SnoopCompile.jl/stable/snoop_pc/
[replit]: https://replit.com/@TomasFiers/Unitful-load-time?v=1

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the current `using Unitful` load path and the package's `src/` layout, then compare the interface-package pattern described for StaticArraysCore. The proposal would be complete when the maintainers agree on the interface package boundary, its dependency relationship with Unitful, and the core types or functions to move.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
backend-api-design, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.