Pathfinder.jl
Pathfinder.jl copied to clipboard
Making Optimization (formerly GalacticOptim) optional
On the 1.8 beta, loading GalacticOptim amd GalacticOptimJL together makes up over half the load time of Pathfinder.
julia> @time_imports using Pathfinder
...
1172.3 ms ┌ GalacticOptim
1237.2 ms ┌ GalacticOptimJL
...
4552.7 ms Pathfinder
This is not ideal, since we use these to support experimentation with other optimizers, not for normal usage. Currently we build everything around GalacticOptim, but perhaps we should make this conditionally loaded and default to doing everything with Optim types.
Relates #36
Note that GalacticOptim is currently undergoing some refactoring to break it down into sub-packages in the same repo.
I believe that already happened with GalacticOptim v3. e.g. we now depend on GalacticOptim and GalacticOptimJL, the latter of which brings the Optim integration.
And that's still too heavy 🤔, interesting.
And that's still too heavy thinking, interesting.
Yes, here's what we get for GalacticOptim by itself:
julia> @time_imports using GalacticOptim
11.0 ms ┌ MacroTools
18.6 ms ┌ ZygoteRules
0.1 ms ┌ IteratorInterfaceExtensions
0.5 ms ┌ TableTraits
502.0 ms ┌ StaticArrays
504.4 ms ┌ DiffResults
1.7 ms ┌ Compat
6.5 ms ┌ OrderedCollections
0.5 ms ┌ Requires
156.8 ms ┌ FillArrays
0.3 ms ┌ DataValueInterfaces
3.1 ms ┌ DocStringExtensions
0.2 ms ┌ IfElse
22.1 ms ┌ RecipesBase
38.6 ms ┌ Static
598.0 ms ┌ ArrayInterface
0.5 ms ┌ Adapt
61.9 ms ┌ ChainRulesCore
755.3 ms ┌ RecursiveArrayTools
0.3 ms ┌ Reexport
5.9 ms ┌ AbstractTrees
2.8 ms ┌ ProgressLogging
5.4 ms ┌ LeftChildRightSiblingTrees
15.4 ms ┌ TerminalLoggers
1.1 ms ┌ DataAPI
13.5 ms ┌ Tables
0.3 ms ┌ CommonSolve
0.8 ms ┌ ConstructionBase
0.2 ms ┌ TreeViews
256.1 ms ┌ SciMLBase
4.9 ms ┌ ProgressMeter
2.1 ms ┌ LoggingExtras
0.8 ms ┌ ConsoleProgressMonitor
1750.9 ms GalacticOptim
Main culprits are:
502.0 ms ┌ StaticArrays
156.8 ms ┌ FillArrays
598.0 ms ┌ ArrayInterface
256.1 ms ┌ SciMLBase
It could certainly drop DiffResults as a dependency, which would get rid of StaticArrays. It's only used in files that depend on other DiffResults dependants. I have no idea why FillArrays is being brought in. ArrayInterface is being used for one function (ArrayInterface.zeromatrix); maybe it could also be dropped. SciMLBase of course not. So maybe it could slim down to not much more than SciMLBase.
https://github.com/SciML/GalacticOptim.jl/issues/239