On Tue, 28 Sep 2004, Greg Guerin wrote:
> The server VM is intended for processes with long lifetimes. It's not just
> that a few routines get executed millions of times. The process itself
> typically has to run for a long enough period of time that the overhead of
> performing the optimizations gets amortized.
That's exactly my point. Many people speak of the server VM as a
panacea for all performance problems, and assert that nearly all programs
should be run with the server VM. Based on my experience, the opposite is
true. The set of programs which consistently perform better with the
server VM than the client VM may be quite small.
Also, the phrase "processes with long lifetimes" is quite deceptive.
How is that to be measured? Ultimately, each routine is optimized
separately. If a million invocations is not enough for it to be optimized
yet, then what is? Or if the overhead to optimize a small handful
of methods takes an extra 9 minutes (over what the client VM takes, which
is measured in seconds), how many hours will it take a large application
to even become usable?
But of course, that's not the point. If the server consistently took
ten minutes to optimize your program, you could work with that. You could
run an automated warm-up process every time you started it, before
allowing clients to connect. Or you could make an educated judgement that
the client VM would give better performance. But when the performance is
wildly unpredicable, it becomes very hard to work with in any useful way.
Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
