Skip to content

load time regressions #4

@colinxs

Description

@colinxs

klowrey/MuJoCo.jl: 0.3s

Lyceum/MuJoCo.jl: 6.7s

Bulk of difference is due to dependency loading:

  • StaticArrays (common to both)
  • UnsafeArrays: 0.02s
  • CEnum: 0.02s
  • MacroTools: 0.32s
  • MuJoCo_jll: 2.78s
  • AxisArrays: 0.17s
  • BangBang: 0.71s

For klowrey/MuJoCo.jl:

julia> @time using MuJoCo, CEnum, MacroTools, AxisArrays, BangBang, MuJoCo_jll
  6.471298 seconds (13.87 M allocations: 693.209 MiB, 2.77% gc time)
julia> @time using MuJoCo, CEnum, MacroTools, AxisArrays, BangBang
  2.916885 seconds (6.23 M allocations: 316.192 MiB, 1.73% gc time)

Note: loading lots of packages at once is greater than sum of loading each individually, from some julia-lang Slack chat this appears to be known issue

UnsafeArrays, StaticArrays, CEnum, MacroTools are common enough that they will almost always be loaded anyways.

AxisArrays cost is minimal.

BangBang is fairly heavyweight, but half of it's load time is from it's dependency on ZygoteRules, which will typically always be loaded as well. BangBang is also pretty necesary for @set!!.

So, only room for improvement is MuJoCo_jll, which stems from GLEW_jll/GLFW_jll/Libglvnd_jll. As a result, only options are:

  1. Ditch GLEW_jll/GLFW_jll/Libglvnd_jll until fixed (can load them manually), which should yield ~3-3.5 s improvement.
  2. Leave and wait until fixed.

Might be worth checking with Elliot to get a rough timeline for when jll load times will be fixed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions