Making Optimization (formerly GalacticOptim) optional

[sethaxen]

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

[mohamed82008]

Note that GalacticOptim is currently undergoing some refactoring to break it down into sub-packages in the same repo.

[sethaxen]

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.

[mohamed82008]

And that's still too heavy 🤔, interesting.

[sethaxen]

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.

[sethaxen]

SciML/Optimization.jl#239