Timing

I knew it was slow when I built it. Where it was slow I did not know until I measured.

Broken out by leg

Leg	Time	Share
sender → receiver (propagation + poll wait)	46s	24%
actually doing the work	27s	14%
receiver → sender (propagation)	118s	62%
round trip	191s

A second round trip measured 133s. Two to three minutes is the honest number.

The bottleneck wasn’t my code

Only 14% is work. The rest is a file crossing, and the return leg alone eats 62%.

The conclusion is the whole point of this page. Shortening the poll interval will not turn this into seconds.

Work out what dropping the poll from 60 seconds to 10 would do. The first leg loses its poll wait, so it drops maybe 20–30 seconds, and the round trip goes from 191s to the 160s. Six times more diligent code, buying 15%.

The return propagation that eats 62% isn’t something I can touch. It’s the sync tool noticing a file changed and pushing it to the peer, and that’s decided by the tool’s configuration and the network.

So it’s a choice, not a tuning problem

If you need seconds, this is the wrong channel. That’s a channel-selection problem, not a tuning problem.

This conclusion matters because before measuring I believed the exact opposite. “The poll is a minute, so that must be what’s slow” is the natural guess — and had I acted on it, I’d have spent time on an optimisation with no effect and then been baffled that it was still three minutes.

That’s where breaking a measurement into segments earns its keep. The total alone gets you as far as “it’s slow.” Splitting it gets you to “the reason is outside my code.”

What it bought instead

In exchange for being slow, this channel has one thing. It arrives even when the other side is asleep.

A file placed in the sync folder crosses when the peer machine wakes, and the watcher picks it up. A chat app just accumulates messages while the recipient is off; here, it proceeds automatically the moment they come back.

Three minutes was the price for that. And that is the entire reason this tool exists.