Skip to content
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

Explanation #2

Closed
AgainPsychoX opened this issue Jun 16, 2021 · 8 comments
Closed

Explanation #2

AgainPsychoX opened this issue Jun 16, 2021 · 8 comments

Comments

@AgainPsychoX
Copy link

Can you explain why is it so much faster?

Why this method not in kernel/base linux or other systems?

@baverman
Copy link

It's very shady that author did not mention copy-on-write anywhere in readme.

@stilgarpl
Copy link

I'd like to know that too. Copy is a simple operation, just read and write, so what does fcp do to make it faster?

@vibecoder
Copy link

Personally, I like to know the details on the reason it is faster other than the performance benchmarks on the README. Otherwise one can always study the code I guess. Also anyone knows what file-system is being used here for the benchmarks?

@vibecoder
Copy link

There is some discussion that took place on the hackernews regarding the same https://news.ycombinator.com/item?id=27523014

@Svetlitski
Copy link
Owner

Svetlitski commented Jun 16, 2021

@AgainPsychoX The primary reason fcp is faster than cp is that it uses multiple threads to walk directories and issue IO requests in parallel, which is advantageous for performance on systems with SSDs. My guess as to why cp doesn't do this is that cp was written back when magnetic hard-drives were the norm, and issuing a large number of IO requests for disparate parts of a hard disk is quite bad for performance as it causes the drive head to seek large distances across the disk.

@Svetlitski
Copy link
Owner

It's very shady that author did not mention copy-on-write anywhere in readme.

Hello @baverman,

Copy-on-write is mentioned implicitly in the footnote explaining the large performance difference on the "Large Files" benchmark run on macOS, which mentions the fclonefileat and fcopyfile syscalls. I can totally see how this is easy to miss though as it appears only in the footnote, and requires the reader to understand that those syscalls perform copy-on-write.

@Svetlitski
Copy link
Owner

Personally, I like to know the details on the reason it is faster other than the performance benchmarks on the README. Otherwise one can always study the code I guess. Also anyone knows what file-system is being used here for the benchmarks?

See my response above and some of the discussion on hackernews than you linked for an explanation as to the performance. The filesystem used for the Linux benchmarks was xfs.

@Svetlitski
Copy link
Owner

An explanation for fcp's high-performance has been added to the README under the "Methodology" section.

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

No branches or pull requests

5 participants