I've put up an alternative JNLP for testing at http://game.havenandhearth.com/java/hafen-test.jnlp. For custom clients, the code is available in the "j8" branch of the public repo (at <git://sh.seatribe.se/hafen-client>), but do keep in mind that the code will have to be rebased a few more times before merging, so don't merge it to anything but a temporary branch. Unless you're really fond of fixing up weird Git conflicts, at least.
The main change that this code brings is that it tries to cache rendered objects that don't change from frame to frame. In particular, this involves caching instanced variants of duplicated objects, which helps tremendously for such things as crops and flavor objects:
While I do think this should help quite a bit with many common scenarios, though, please do note that it's not like it's the be-all and end-all of optimization. To begin with, not all objects that this system could potentially cache are currently cachable. These things include, in particular: things with variable materials; potentially animated things that are currently still; and dead animals. The difficulty involved in making those things cachable increase in order of that listing. Other things are inherently uncachable; these include in particular animated things, which then includes such things as live hearthlings or animals, hearth fires, bee hives or fully loaded trash stockpiles. There may well be other optimizations applicable to such things, but they are not incorporated in this change.
Also, this system only applies to the CPU side of performance. For those whose main bottleneck is the GPU, this update does nothing at all. However, with a little bit of hope, these changes may perhaps move the main bottleneck to the GPU for now. In that case, the task I would need to undertake would be to profile the GPU usage of the client and see in what ways it could be improved.
Another thing which is loosely related to performance that I'd like to fix soon-ish is that the current implementation of parallel rendering entails some output latency. It buffers completed frames in an unfortunate way that I suspect feels like a performance problem when using the client, even though it's not FPS-related.
Also note that this client does indeed require Java 8. If it works, and I merge the changes, then the client would always require Java 8. Please speak up if this is a problem.
Anyway, I hope there aren't any grievous bugs in there, but if there are, I hope you find them.