Broccoli: Syncing faster by syncing less (2020) • Hacker News Board

Eric_WVGG wrote: post #9

gigatexal wrote: post #4

As long as this makes the client on Mac use less resources than a fork bomb I’m all for it.

It doesn’t, the client code is still a dumpster file. Give Mistrael a look. Anecdotally ~7x less RAM, ~10x less disk space. https://maestral.app

Is there anything like this for Windows?

Re: Broccoli: Syncing faster by syncing less (2020)

#14

Post by QuadrupleA » Sun, Dec 12, 2021, 4:56 PM UTC

All this talk of efficiency, yet the Dropbox windows client is such a bloated multi-process memory hog of a mess that I ended up uninstalling it and rigging my own sync with a command line tool (dbxcli), with about 1000x less resource usage.

For all this attention to saving their server's resources they sure don't seem to care much about wasting their customers'.

Re: Broccoli: Syncing faster by syncing less (2020)

#15

Post by kevinday » Sun, Dec 12, 2021, 4:59 PM UTC

gampu wrote: post #5

donatj wrote: post #3

> Rolling out the above changes went relatively smoothly until one of the curious engineers on our network team found that compression was actually a bottleneck on high bandwidth connections Back in the early-to-mid-aughts there was a push to start gzip-ing server responses. It was my general experience at the time that this actually often made the browsing experience worse. Whereas without compression the page would…

Not sure how compression was a bottleneck on the high bandwidth connections? I understand @donatj's comments about having to wait for the entire file to be downloaded before rendering, but that would be a user experience issue, not sure how the network team sees it as a bottleneck on the network?

HTTP requires that the length of the content be sent before the content, so that pipelined connections know where the data ends and the next headers start. If you're sending a file directly off disk you know the size before you've even looked at the data so there's no delay. If you're running everything through gzip, you have to wait to compress the entire file before you know the output length, so the critical "time to first byte" metric could get much worse. There are similar issues with dynamic content (CGI scripts, PHP, etc) where both the server and browser would end up buffering large amounts of content before compressing/decompressing them, which also affected perceptual speed. If the connection bandwidth was high enough, skipping all of this and just sending the uncompressed file would appear faster to the user, despite transferring more.

This was later improved with things like chunked encoding and caching the compressed output on the server side, but they came later and weren't always supported or desirable.

Re: Broccoli: Syncing faster by syncing less (2020)

#16

Post by howdydoo » Sun, Dec 12, 2021, 6:12 PM UTC

QuadrupleA wrote: post #14

All this talk of efficiency, yet the Dropbox windows client is such a bloated multi-process memory hog of a mess that I ended up uninstalling it and rigging my own sync with a command line tool (dbxcli), with about 1000x less resource usage. For all this attention to saving their server's resources they sure don't seem to care much about wasting their customers'.

This is classic.

"We spent $x million developing a compression algorithm in Rust to slightly speed up a background process in our bloated Electron app!"

Re: Broccoli: Syncing faster by syncing less (2020)

#17

Post by davidjade » Sun, Dec 12, 2021, 6:42 PM UTC

I really wish this idea had become more widespread. Microsoft Research published this 15 years ago. It shipped as part of windows but the paper describes it in enough detail to implement it I think. I got it running years ago and it seemed to work really well.

https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: Broccoli: Syncing faster by syncing less (2020)

#18

Post by jeffybefffy519 » Sun, Dec 12, 2021, 7:24 PM UTC

Why cant you guys enable multiple account sign ins from the one dropbox client. So annoying.

Re: Broccoli: Syncing faster by syncing less (2020)

#19

Post by irq-1 » Sun, Dec 12, 2021, 8:18 PM UTC

davidjade wrote: post #17

I really wish this idea had become more widespread. Microsoft Research published this 15 years ago. It shipped as part of windows but the paper describes it in enough detail to implement it I think. I got it running years ago and it seemed to work really well. https://www.microsoft.com/en-us/research/wp-content/uploads/...

Interesting. Looks like Windows does use it the Distributed File System Replication (DFSR) service.

https://docs.microsoft.com/en-us/previous-versions/windows/d...

Re: Broccoli: Syncing faster by syncing less (2020)

#20

Post by hedgehog » Sun, Dec 12, 2021, 10:05 PM UTC

howdydoo wrote: post #16

QuadrupleA wrote: post #14

All this talk of efficiency, yet the Dropbox windows client is such a bloated multi-process memory hog of a mess that I ended up uninstalling it and rigging my own sync with a command line tool (dbxcli), with about 1000x less resource usage. For all this attention to saving their server's resources they sure don't seem to care much about wasting their customers'.

This is classic. "We spent $x million developing a compression algorithm in Rust to slightly speed up a background process in our bloated Electron app!"

The Electron app wouldn't be an issue if it didn't churn away uselessly even when Dropbox is in the background. The company doesn't care though, their advice was to open a topic in the support forum, to which their response is "This idea will need some more support before we can share it with the team." You can lead a horse to water.