I should have added that uploading files runs at 1/10th, sometimes 1/15th of the throughput the speedtest.dropbox.com utility says I should have. I have a 100/100 Internet service. I suspect the culprit is that the 32-bit dropbox client is cpu-bound to 1/12th of the total cpu in my 12-processor desktop. Is that the clear technical need you need? BTW I tried uploading directly onto AWS and I didn't have any speed problems. I have a 10TB business account with you.

No, that isn't a clear technical need, infact it quite badly misses the heart of the problem.

Dropbox being 32bit has no bearing on whether it is running multiple threads or not. I can run a 1024 threaded application on your 12 core desktop without ever stepping outside of the capabilities of 32bits. Similarly, I can run a 1 thread 64bit application on the same computer.

The only thing that 64bits gives you is a larger address space - and if Dropbox needs more than the 4GB address limit of 32bit then we have a larger problem.

Dropbox being 32bits is not the thing causing it to not max out your internet connection, nor is it the reason the Dropbox client doesn't max out processing on all your cores. Compiling Dropbox for 64bit won't solve those issues - one is internet connection bound, the other is a software design and implementation decision.

What do you mean there is no clear technical need? Have you done benchmarking of 32-bit vs 64-bit binaries? Or is this "I don't know why it may help, so it must not be helpful"-type of statement? 64-bit binaries allow for 64-bit address space. Which allows all file IO to be done through the most efficient mechanism available: file memory mapping. With 32-bit executables this is still possible, but requires constant mapping/unmapping. And each one of these mapping/unmapping is an extra system call. System calls are time-consuming operations. Which is why having a sparsely-consumed memory space usually produces faster executables. Given today's memory and file sizes, 32-bit executables are almost certainly using densely-consumed program memory space. It doesn't mean that the actual memory used by the program is higher, but it does mean that the program has to make more system calls.

I am thinking the same thing Skip. 32 bit confined with this "clear business need" along with when opening the MOVE option in any browser, it is purposefully scaled to 1/10 or less of the screen - tiny little file folder window - to discourage using browser interface. Guess what... I don't keep but 10% of my files local (meaning you guys save big on bandwidth, most of mine is parked there, not synced) - yet you have this little peep hole to move files with.

DRIVE does not do this, does not consume a constant 4GB of active memory consumption, and frankly they seem quite tuned into the "suggestion box", not "not clear business need".

However you frame it, need or not, that's the fundamental no service bad service DBox model playing out. It stinks.