Skip to content

Conversation

@rxxg
Copy link
Contributor

@rxxg rxxg commented Jan 9, 2020

  • ❗ Have you followed the guidelines in the Contributing to DVC list?

  • πŸ“– Check this box if this PR does not require documentation updates, or if it does and you have created a separate PR in dvc.org with such updates (or at least opened an issue about it in that repo). Please link below to your PR (or issue) in the dvc.org repo.

  • ❌ Have you checked DeepSource, CodeClimate, and other sanity checks below? We consider their findings recommendatory and don't expect everything to be addressed. Please review them carefully and fix those that actually improve code or fix bugs.

Thank you for the contribution - we'll try to review it as soon as possible. πŸ™

Improves performance for Windows network shares (#3084).
Be aware, it uses a patched version of the external library speedcopy, so I don't expect you will want to pull as-is.

Also - my local tests (Windows machine) showed 17 failures, but no new ones from the base case.

@efiop
Copy link
Contributor

efiop commented Jan 9, 2020

@rxxg Thanks for the PR! Looks like speedcopy doesn't work on *nix. Btw, how did the dvc add speed change with speedcopy?

@rxxg
Copy link
Contributor Author

rxxg commented Jan 9, 2020

On my tests I'm getting native-level performance on file copies.
Sorry, I no longer have access to a Linux machine at work so I wasn't able to test beforehand. There is an equivalent project called pyfastcopy - I'll push another modified untested patch.

@efiop
Copy link
Contributor

efiop commented Jan 9, 2020

On my tests I'm getting native-level performance on file copies.

Not sure I follow. You've provided examples of createnew and dvc add timings before. So I wonder how much time dvc add on your network share takes now? Note that those tests should be done on a new repo, so that second dvc add doesn't find previous file already in cache. ALso need to ensure that you don't have cache.type configured in .dvc/config, and so still using copy links.

@rxxg
Copy link
Contributor Author

rxxg commented Jan 9, 2020

What I meant was that dvc add now takes about the same time as md5sum + network copy on my system. So from my point of view the performance is now acceptable, although I would love to get server-side copy working so that the network hit completely disappears for the copy (still have to do a network read for the md5sum).

On the downside, I have no way of testing a *nix equivalent, hence the repeated Travis failures. I suppose the easiest thing would be to only activate the functionality on Windows. What do you think?

@efiop
Copy link
Contributor

efiop commented Jan 10, 2020

@rxxg Those are amazing results! πŸŽ‰ Btw, is it even possible for us to trigger server-side copy?

@efiop
Copy link
Contributor

efiop commented Jan 10, 2020

Be aware, it uses a patched version of the external library speedcopy, so I don't expect you will want to pull as-is.

Yeah, that is not very nice. I see you've already submitted the patch to the upstream and the maintainer is pretty active, so looks like we will be able to use an officially released version soon 🀞

dvc/system.py Outdated
import shutil
import sys

if sys.version < (3, 8):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if sys.version < (3, 8):
if sys.version_info < (3, 8):

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So 3.8 already uses sendfile? neat!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream speedcopy works for both Linux and Windows now. I will let you make the judgement as to whether to use speedcopy or pyfastcopy for the Linux side.

As you say, 3.8 should be faster, but they have taken a different approach on Windows (not using the win32 API). I don't know whether whether that is faster/more robust, probably worth revisiting when DVC is 3.8-compatible. It might be worth moving the version check higher up so that on 3.8 shutil always gets used.

@efiop
Copy link
Contributor

efiop commented Jan 10, 2020

@rxxg This looks amazing! πŸŽ‰ And will speedup *nix as well as windows, which is amazing^2. Thank you so much for contributing! πŸ™ Please see some minor comments above.

@rxxg
Copy link
Contributor Author

rxxg commented Jan 10, 2020

Be aware, it uses a patched version of the external library speedcopy, so I don't expect you will want to pull as-is.

Yeah, that is not very nice. I see you've already submitted the patch to the upstream and the maintainer is pretty active, so looks like we will be able to use an officially released version soon 🀞

There are hardly any upstream tests, and the *nix code is very different from the Windows version, so I am slightly wary about the code quality of the speedcopy project. Are you are confident with the DVC test suite coverage?

@rxxg
Copy link
Contributor Author

rxxg commented Jan 10, 2020

Btw, is it even possible for us to trigger server-side copy?

I don't know ... I am on a journey of discovery πŸ˜‰

I found this page which claims that server-side copy will be triggered by Windows explorer for compatible servers (so I assume that one or more of the win32 API points makes use of it behind the scenes) and for Linux for cp -reflink. However something is clearly not working on my local setup. Coincidentally I am working from home today so it would really, really be useful to me - a 1Mb file copy takes 10 seconds 😒

[EDIT] Not working with robocopy either, so I'll follow up internally to see if there is anything we can do server-side to speed things up.

@efiop
Copy link
Contributor

efiop commented Jan 11, 2020

Coincidentally I am working from home today so it would really, really be useful to me - a 1Mb file copy takes 10 seconds 😒

Why not remote login into your work machine instead? πŸ™‚

@efiop
Copy link
Contributor

efiop commented Jan 11, 2020

There are hardly any upstream tests, and the *nix code is very different from the Windows version, so I am slightly wary about the code quality of the speedcopy project. Are you are confident with the DVC test suite coverage?

Yeah, a bit worried about that myself. But our test suite is quite good. If we feel too sketchy about it, we could make this optimization an opt-in by introducing some config option.

@efiop
Copy link
Contributor

efiop commented Jan 11, 2020

@rxxg Btw, please rebase. There has been some temporary issues with the test suite, which are now resolved.

@rxxg
Copy link
Contributor Author

rxxg commented Jan 11, 2020

@rxxg Btw, please rebase. There has been some temporary issues with the test suite, which are now resolved.

Done ...

@ghost
Copy link

ghost commented Jan 14, 2020

Woah, jumping late to the discussion but thanks a lot for the patch, @rxxg , those improvements are awesome!

What's missing to merge this one?

@rxxg
Copy link
Contributor Author

rxxg commented Jan 14, 2020

Woah, jumping late to the discussion but thanks a lot for the patch, @rxxg , those improvements are awesome!

What's missing to merge this one?

We're working off a patched copy of an upstream library, which is not great. I'll see if I can get the maintainer to do a minor version release.

BTW, I messed up and deleted my fork, so I'm closing this PR and starting a new one (with the same code).

@rxxg rxxg closed this Jan 14, 2020
@rxxg rxxg mentioned this pull request Jan 14, 2020
3 tasks
@rxxg
Copy link
Contributor Author

rxxg commented Jan 14, 2020

Superseded by #3135.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants