-
Notifications
You must be signed in to change notification settings - Fork 17
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
PERFORMANCE: Search large X
:s for globals is slow [SOLVED]
#13
Comments
…lements that are lists Related to: futureverse/future.apply#13
X
:s for globals is slowX
:s for globals is slow [SOLVED]
I've updated remotes::install_github("HenrikBengtsson/globals@develop") (*) There will still be cases where this improvement won't help, e.g. long lists which in turn contains lists. |
This is definitely helpful. I was just doing some testing iterating over Any timeline on an updated |
globals 0.12.1 hit CRAN ~10 hours ago. |
In future.apply 1.0.0,
future_lapply(X, ...)
searches alsoX
for possible globals (Issue #12). For longX
:s this introduces a significant overhead, especially ifX
does not contain any globals and we wouldn't have to searchX
in the first place. For example,All the slowness comes from an internal:
Following the code, this is slow because
is slow, which in turn is because it effetively does:
We might be able to speed up
globals::findGlobals()
a bit here,but don't know how much.[UPDATE 2018-06-20]: there was a low-hanging fruit in the globals package making it possible to speed this up lots, cf. futureverse/globals@566e3e9. I'll be running revdep checks on globals (first and and second generation dependencies) to make sure this doesn't break anything. If all ok, the need for working around this in future.apply is much smaller.Regardless, there could be a need for an argument controlling whetherX
should be searched for globals or not, especially since it is likely that in most use casesX
does not have globals.The text was updated successfully, but these errors were encountered: