Comment 6 for bug 889084

Revision history for this message
ClashTheBunny (spam-mason) wrote : Re: [Syncany-team] [Bug 889084] Re: Java memory usage

Syncany is a beast. Syncany is not just Dropbox or SparkleShare.
Syncany actually does encryption of the data, they built the
infrastructure for block chunking with deduplication, they have
multiple backends. This is a feature full program; that isn't a
simple thing. If you use ZFS with deduplication you need many
gigabytes of memory and it's not doing encryption. Add the
compression and you get even worse memory usage. People who have
storage arrays of a few terabytes have systems with 16GB of RAM and
the ARC Cache alone takes up 6 GB or so during normal usage. This is
a fully featured program. ZFS in software almost. It's not something
simple like Dropbox.

If you can come up with a closer analog than ZFS that uses much less
RAM and has better startup times, I would love to see it. I've been
looking for a while and still haven't found an optimal storage
platform. If my Android phone, a memory limited device, can handle
many complicated tasks and run fairly quickly, I don't think it's Java
that's the problem. It's a combination of memory hungry, processor
intensive features and bugs that need fixing.

This is opensource. If you have such a strong opinion on what
language should be used for this project, you are free to take it and
port it. You have that freedom. With opensource, you are never in a
position where you can demand or complain. Come with data, like a
profile that shows where the code spends a lot of time or wastes a lot
of memory. Come with a patch. We all want this to be better. One of
the points of opensource is acknowledging that we aren't smart enough
ourselves and we need help with this.

Finally, when the new code is pushed, there will be better
opportunities to target specific parts. If you want a daemon written
in C or Python, it will be easier. This architecture issue is on the
TODO and will make it much easier to tackle this type of problem.
This way it will be easier to think of Syncany less as a specific
program, like AIM, but more like a protocol, like XMPP. When a
Syncany client is written for iOS, it will be written in Objective-C,
when it's written for Android, it will be in Java, when it's the
backend, there may be a couple of different backend implementations
with different advantages. We will, hopefully soon, have that
freedom.

R. Mason
<email address hidden>