-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StaticArrays load time, possibility for abstract interface package? #1023
Comments
As far as I know the time spent in loading The most complicated part of work here is determining which methods shouldn't be moved to StaticArraysCore.jl which requires some cooperation from maintainers of major packages that use StaticArrays.jl. |
Yes - there are some packages that really utilize StaticArrays for what they do - they're little that can be done there, of course. But then there's packages that only need StaticArrays to add some compatibility with it (e.g. this code I have in ArraysOfArrays, via I'm not quite sure in which of these categories ForwardDiff falls (StaticArrays is a big part of it's load time). |
I've just made a quick test and just removing advanced linear algebra gets us down to about 0.17-0.20 s (depending on the details). Would that be fine? Or do you think it's still too much? |
I guess it depends on how much it is relative to the package that depends on StaticArrays. :-) I worry a bit about having a "stripped down" version of StaticArrays that contains concrete types (not just and interface) without full functionality. In applications that use a lot of generic code, the "full" StaticArrays might not get loaded automatically, leading to non-performant behavior (or maybe even errors due to missing functionality). |
Maybe having abstract static arrays would be enough to satisfy the needs of many packages now depending on StaticArrays, esp. if they use |
If a package only had the abstract type and some functions, it wouldn't have |
I have to admit that example wasn't ideal.
And I could actually drop But you're right, an abstract interface would not be sufficient. It would be better to move these definitions from ArraysOfArrays into StaticArrays itself. I'm currently in the process of moving the AbstractArrays interface into AbstractArraysOfArrays (currently under design). AbstractArraysOfArrays will be super-lightweight, so it should be an acceptable dependency for StaticArrays. |
Does that mean that even an |
Well, we need to know the difference between MArray and SArray since MArray is mutable, so we want a higher level type for immutable static arrays, but yes if there was an abstract type for those then we'd have all we need because we could just do |
So maybe an
Wouldn't |
ArrayInterface has drastically improved load times recently and provides much of the tooling necessary to propagate static information between methods. The tools to construct an immutable array in place are not yet fully implemented but most of the hesitation in implementing that has been due to the lack of solid details on how |
I've started working on an small interface package: https://github.com/JuliaArrays/StaticArraysCore.jl . What do you think? |
I think that's precisely what we need. |
Should we consider moving |
Update: I have finished the first version of StaticArraysCore.jl and triggered registration: JuliaRegistries/General#61901 . Once that goes through I will make a PR to StaticArrays.jl that makes it implement that interface. |
Would it make sense to put StaticArraysCore.jl in the same repo as StaticArrays.jl (but in a subfolder)? (As in Makie, ArrayInterface, etc.) |
I have never made a repository with more than one package so I don't know. |
It works just the same as the usual thing, except the package lives in a subdirectory and registrations use I think the main things to consider are integration with CI; i.e., does one test StaticArrays.jl on the master of StaticArraysCore or on the most recently released version. One benefit is that all of StaticArrays.jl's test could run on PRs to StaticArraysCore.jl as well. |
We could just merge the two. We already replace the static ranges with our types in ArrayInterface. |
OK, so if we wanted to have StaticArraysCore.jl in this repository, how would we do that? Do we keep the current StaticArraysCore.jl registration PR open and then change the repository URL? Or close that PR and trigger a new registration from here? |
I don't know which is easier; either could work, I believe (but maybe just closing that PR and opening a new here would be easier?). If we do the latter, it could be a PR to StaticArrays.jl that creates a subfolder StaticArraysCore.jl with all the content (modulo the CI stuff) from the current StaticArraysCore.jl repo. After we merge that, we could then register it in the usual way (just with the additional |
It's really up to you what you want to do. It's easier to keep the conversation for PRs all in one place, but it's also easier to track code coverage in separate repos |
Since the repository is already created, maybe let's keep it for now. It can always be changed later. |
I can make a PR to StaticArraysCore in a bit to merge the features of ArrayInterfaceStaticArrays so we can see what that would look like. |
Sub repos seemed to be a lot simpler to setup if the sub is a dependent on the main, not the other way around. ArrayInterfaceCore flipped this and caused a few CI hiccups, but it is nice to be able to test it all together given how it's interrelated. Repos like Optimization.jl where all of the subs depend on Optimization.jl (another case, KernelAbstractions.jl) seem to be the most ideal use case for a multi-package repo. |
Which features? |
Is Optimization a successor of GalacticOptim? |
The only reason it depends on |
Yes. It's GalacticOptim but everyone on the Discourse and Slack voted for a rename, so it happened. Same with Quadrature -> Integrals. Now https://docs.sciml.ai/dev/ is a lot more clear. |
Or the best thing would be to start upstreaming a lot more of it to Base. |
I like it! Now we just need to get it's load time down further. ;-) |
Awesome! I'd love to start using this, e.g. to make ArraysOfArrays.jl get by without |
I'm planning to submit a PR to StaticArrays.jl that makes it depend on StaticArraysCore.jl next week. |
Thanks a lot @mateuszbaran ! |
I have made the PR: #1045, now I need a review 🙂 . |
So, this is now completed by merging #1045. |
Thanks so much, @mateuszbaran ! |
StaticArrays (together with ArraysInterface) seems to be a driving factor in package load times nowadays. For example, the load time of FiniteDiff, FiniteDifferences and ForwardDiff (common direct/indirect dependencies themselves) themselves is mainly due to StaticArrays (and ArrayInterface):
Even the load time of a "large" package like Optim is completely dominated by StaticArrays and ArrayInterface (indirectly, via FiniteDiff and ForwardDiff):
There's currently and effort to make ArrayInterface more lightweight by splitting it up (JuliaArrays/ArrayInterface.jl#211) - I wonder if the same would be possible for StaticArrays? Would something like an AbstractStaticArrays be enough for packages like the above? I think at least some of them only "support" static arrays but don't use them for their core functionality (I may be wrong).
The text was updated successfully, but these errors were encountered: