> It doesn't seem to me that the optimization under discussion would make a
> lot of difference either way on the server. In fact, if the server-side
> serialization code is generated, there's no reason it couldn't be pretty
> much optimal.

> As Sandy points out, though, generating code on the server is a bit of an
> issue if you don't want to recompile your server all the time. Maybe there's
> a way to make this optional, but it is certainly a consideration.

> One benefit to the client I want to mention is that, in addition to making
> the code much *faster*, it will also make it much *smaller*. The
> deserialization code can be quite significant, and I'm all for doing
> anything that eliminates client code.

> On 6/6/07, The Class Connection <theclassconnect...@gmail.com> wrote:

> > > > 4) What's more important, server-side performance (of RPC response
> > > > construction), or client-side performance (of RPC response
> > > > deserialization)?

> > > I have to vote for client-side performance being more important.  If
> > > my server is too slow I can buy a bigger one or another one.  If my
> > > client is too slow, I can do nothing more than beg my customer to buy
> > > a newer machine.

> > I vote server-side performance being more important.  I am less than
> > happy with my explanation, but I have yet to think of a better way to say
> > the following:  As server-side work scales with the number of users, so does
> > the savings given by any server-side optimization.  The client side's
> > optimization has a much smaller visible impact as each user sees a constant
> > improvement, not a scaling improvement...

> > Also, my server is going to get run to its limits.  My site is going to
> > have more than a mebibyte of downloaded code before a user can use the
> > interface.  I expect my audiance to be primarily broadband users, people
> > who, I expect, will have more than enough headroom to deal with the lack of
> > client-side optimization...