remote: use string paths over PathInfo for performance reasons #3672
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pmrowla
changed the title
pmrowla
force-pushed
the
3635-remote-local-pathinfo
branch
from
9cb7a0f to
654b606
Compare
|
|
pmrowla
force-pushed
the
3635-remote-local-pathinfo
branch
from
75cffe8 to
9d4a3b8
Compare
pmrowla
changed the title
pmrowla
changed the title
pmrowla
force-pushed
the
3635-remote-local-pathinfo
branch
from
0f69c29 to
c4863b1
Compare
- cloud remotes still default to using PathInfo's
- if path is not relpath from cwd or abspath, posix lstat() syscall runtime doubles (from calculating relpath from cwd)
pmrowla
force-pushed
the
3635-remote-local-pathinfo
branch
from
b17446f to
33ec6d7
Compare
pmrowla
commented
Apr 27, 2020
| @@ -67,6 +67,13 @@ def cache_dir(self, value): | |||
| def supported(cls, config): | |||
| return True | |||
|
|
|||
| @cached_property | |||
| def cache_path(self): | |||
| return os.path.abspath(self.cache_dir) | |||
There was a problem hiding this comment.
If path is not abspath or relpath from current working dir, posix lstat() syscall runtime doubles. PathInfo.__str__ uses relpath from cwd, but since cwd may change during runtime (like in some of our erepo tests), we can't cache relpath(self.cache_dir) and we don't want to compute it each time, so we just use abspath.
pmrowla
changed the title
|
@efiop solution is more generalized now. |
efiop
approved these changes
Apr 28, 2020
skshetry
added a commit
to skshetry/dvc
that referenced
this pull request
Jun 14, 2020
PR iterative#3672 (6d8499e) extended `LocalRemote::_get_plans` to return one `checksums` too. As all of the args from `_get_plans` was passed down to `download()`, it recognized extra arg of checksum as `no_progress_bar` due to which it became True and stopped showing progress bar at all. Fix iterative#3874
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
❗ I have followed the Contributing to DVC checklist.
📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here. If the CLI API is changed, I have updated tab completion scripts.
❌ I will check DeepSource, CodeClimate, and other sanity checks below. (We consider them recommendatory and don't expect everything to be addressed. Please fix things that actually improve code or fix bugs.)
Thank you for the contribution - we'll try to review it as soon as possible. 🙏
Should close #3635.
statusandLocalRemote.cache_exists)_process/upload/downloadpipeline has been left alone for now - in the event that we are pushing or pulling enough files that using PathInfo's becomes noticeably slow, the expectation is already going to be that the operation will be slow, given that we will be uploading/downloading a lot of data.