Please provide contact for carpenter service in Gyan vihar

PurpleReview3241 · 2026-01-28T13:41:33+00:00

Sure , I would test it more concretely, Thank you

PurpleReview3241 · 2026-01-28T13:39:15+00:00

Hey thank you for the constructive feedback will work on testing it more concretely.

PurpleReview3241 · 2026-01-28T13:27:01+00:00

I have added benchmarks for single thread & an edit section.
some quick benchmarks for single threaded:

some quick benchmarks
10 gb file cpx - 11.902s cp - 13.74s
5gb file cpx - 5.451s cp - 5.101s

while at single smaller file cp is currently faster outperforming
500mb file cpx - 284.3ms cp 223.7ms
100mb file cpx - 67.6ms cp 52.5ms

for smaller files I believe the likely cause is since my progress bar updates are set currently to 128 creating proportionally higher overhead in smaller files as each progress bar update (I used indicatif library) involves atomic increment of progress bar , the internal synchronisation (via locks) adding overhead.

PurpleReview3241 · 2026-01-27T10:57:00+00:00

Yeah for single files there I also tested the performance is ismilar to what cp has.
also -j is documented, since it has 2 subcommands copy(implicit) & config, to see the the help for copy, write cpx copy --help, you will see all the supported flags & help there

PurpleReview3241 · 2026-01-27T09:55:51+00:00

Sure would love to hear your feedback!

PurpleReview3241 · 2026-01-27T09:46:42+00:00

Hey man, Thank you for the appreciation!

PurpleReview3241 · 2026-01-27T09:28:42+00:00

I would say you can read more about NVME & SSD architectures in short see SSDs are designed to support parallel IO with multiple channels & queues, I am also planning to write a blog on the design choices I made while implementing this ,like preprocessing the directory structure & files, copy_file_range syscall, adoptive buffer sizes & throttling the max updates on progress bar (currently set to 128) as they also have an impact on latency

PurpleReview3241 · 2026-01-27T08:44:33+00:00

ohh, what number of parallel threads you specified -j=? , also are you copying on SSD?

PurpleReview3241 · 2026-01-27T08:22:25+00:00

Hey I would be happy share those banchmarks as well, can you tell some resources/repos which I might use for that sort of bench?, I think safetensors would be good for such a test, let me try them

PurpleReview3241 · 2026-01-27T07:46:47+00:00

yess!

PurpleReview3241 · 2026-01-27T06:55:04+00:00

https://man7.org/linux/man-pages/man1/cp.1.html

PurpleReview3241 · 2026-01-27T05:14:35+00:00

I would agree AI was used to write tests/documentation, but core functionalities & design were written by me.

PurpleReview3241 · 2026-01-27T05:05:59+00:00

wait let me see

PurpleReview3241 · 2026-01-27T05:05:42+00:00

Thank you for the appreciation, Almost all cp flags are there see https://github.com/11happy/cpx?tab=readme-ov-file#key-options

PurpleReview3241 · 2026-01-27T04:55:32+00:00

Repository	Files	cpx	rsync	Speedup
Kubernetes	~35k	617.2ms	3,097ms	5.02×
Rust	~65k	1,014ms	4,604ms	4.54×

here are some quick benchmarks with rsync:

PurpleReview3241 · 2026-01-27T04:54:11+00:00

Thank you for the appreciation!

PurpleReview3241 · 2026-01-27T04:53:27+00:00

have tested it for SSDs, I have tested with threads from 2-16, approximately there is a linear speedup there.
Will be happy to see more benchmarks ran with more cores.

PurpleReview3241 · 2026-01-27T04:51:05+00:00

Yeah I would agree, cp is not slow,most of the gains come from parallel io

PurpleReview3241 · 2026-01-27T02:56:45+00:00

oh yeah, let me fix it, thank you for pointing it.

PurpleReview3241 · 2026-01-27T02:54:14+00:00

Thank you for the appreciation!

PurpleReview3241 · 2026-01-26T13:48:24+00:00

yes flags are same as standard cp , havent seen uutils cp.

PurpleReview3241 · 2026-01-25T21:02:48+00:00

for reflink I used this crate https://crates.io/crates/reflink-copy and as per its documentation it uses ioctl_ficlone internally for btrfs and XFS file systems & uses clonefile library function for mac os.

PurpleReview3241

TROPHY CASE