Wow, that's not half as bad as I thought it would be. If you'd like to move forward with contributing it, the next step is creating a JIRA ticket and having someone (probably me) dig through it.
On Fri, Jul 23, 2010 at 6:38 AM, Emmanuel Bourg <[email protected]> wrote: > Le 22/07/2010 22:35, Bryan Duxbury a écrit : > > > One question I have in general, though, is why does the size of the jar >> matter at all? It's not like it's going to take up tons of memory or slow >> you down particularly when being transferred around. >> > > Thank you for the look at my suggestion. > > I wouldn't bother reducing the size of the jar for a server application, > but for a desktop application I have to care about the size of the files > downloaded. I guess 3MB for a RPC interface was beyond my threshold of pain. > > The performance is definitely important. In my opinion it's more important > on a server handling several requests continuously than on a client > launching some requests sporadically. It really depends on the use cases. > > I took some time to run my modification through the serializer benchmark > [1]. Without optimization it's 46 times slower than the static code. With a > naive cache it's only 2.3 times slower, which is acceptable for my use case. > And there is certainly room for improvements with dynamic bytecode > generation. > > Emmanuel Bourg > > > [1] http://github.com/eishay/jvm-serializers > >
