On 02/09/2012, at 10:05 AM, Joern Huxhorn wrote: > Hey Adam, > > I'd suggest you take a look at protobuf if you haven't done so already. > > I've done a comparison some time ago over at > http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance and I > use it extensively in Lilith. > > Protobuf is cross-platform and can be both forward- and backward-compatible > if used with care (tag every message element optional and don't reuse IDs).
It's certainly an option we're looking at. > > Joern. > > On 29.08.2012, at 21:23, Adam Murdoch <[email protected]> wrote: > >> >> On 30/08/2012, at 3:34 AM, Spencer Allain wrote: >> >>> I was tracing the network traffic between the gradle client process and the >>> gradle daemon and was wondering if Java Serialized Objects make the most >>> sense from a portability standpoint, especially since there is >>> consideration of creating a native client to communicate with the daemon to >>> mitigate JVM startup time concerns. >>> >>> Short of using something like Excelsior JET, a directly compiled executable >>> will be implemented in some other language besides Java, precluding easy >>> use of Serialized Objects. >> >> There are a few options we still need to spike for implementing a native >> client in Java (e.g. java to c translation, gcj), but my guess would be that >> we'll end up with a c based client. >> >> Ignoring the cross-language aspect, we want to move away from Java >> serialisation for other reasons: better performance and better support for >> schema changes. >> >> There are many places in Gradle that would benefit from improved >> serialisation: >> >> * The client to daemon protocol would become portable, faster and >> cross-version. >> * The daemon registry would become cross-version, which means daemon >> management can be cross-version (e.g. stop the daemon for all versions, the >> daemon timeout can consider how many daemons are running across all >> versions). >> * The worker process to Gradle protocol would become faster, which means >> faster test execution and compilation. >> * The artefact meta-data cache and the incremental build cache would become >> smaller and faster. Everybody wins with this. >> >> I hope to start rolling out some of this in maybe the 1.3 or 1.4 release, >> but initially focused on performance rather than portability. The current >> plan is to start with the worker process protocol, as profiling suggests >> this should benefit nicely from improved serialisation, and then move on to >> the caches. But we might switch the order around if there's good reasons to. >> >> >>> >>> Two obvious portable data serialization formats are JSON and Google >>> Protocol Buffers, each with different advantages and disadvantages. Not >>> saying that either one should become the data transport protocol to/from >>> the daemon, but just listing them as potential alternatives. >>> >>> Instead of replacing the current communications, alternatively, there could >>> be a (potentially more limited) adapter for separate control on a different >>> port that uses something other than Java Serialized Objects for the >>> transport mechanism. >> >> We might do something like that to get the native client moving, but the >> goal is to end up with a single portable protocol. >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
