Box2D Forums

that would be great. private members would be fine too as long as they're not static.


ewjordan, should I worry?

Hmm - well, I don't know if you have to worry at the moment. I just looked through the engine for statics of every kind, and the only class with static private vars used for "pooling" is CollidePoly, which has a couple Vec2s and a couple XForms; it appears that all the other cases I finally got rid of via manual scalar replacement (i.e. ripping out the objects and doing the calculations with floats instead - FWIW, the -server Java 6u14 (and up) with the -XX:+AggressiveOpts flag can supposedly do this optimization automatically, which is a very neat escape analysis trick! I don't think it works perfectly yet, but it does give JBox2d a ~10% speedup; sadly, it probably won't be in the client JVM for a long, long time, if ever...). With more than one thread simulating, there's a very real possibility that gets/sets to these variables might interleave, which could lead to glitches (that's more likely as the number of parallel worlds increases).

There are a few options to deal with that:

1) replace the private statics with thread-local temps
2) forget all that and just inline that stuff away so we don't need to worry about it, or
3) create a thread-safe temp pool, so that you can always grab a temp vector and know that no other object has access to it, which is a lot more subtle to get right than it might appear at first glance (true about everything once concurrency enters in).

While 1) and 3) are the "right" design solutions from the point of view of code cleanliness, 2) is probably less work overall, and should give better performance, so I'll see if I can do the inlining some time soon. It's a very worthwhile goal especially for this case since poly-poly collisions are the meat and potatoes of any physics engine and deserve as much optimization as humanly possible (and the place where those temps are used still creates some garbage anyways, which is bad!). I'll post a note when I update that file.

BTW, Eclipse (and probably other IDEs) makes inlining fairly simple, on Windows the key command is alt + shift + I, then you just clean up the code (it usually works just fine, but could be simplified a bit). The only real problem with scalar replacement is that sometimes there are methods called that take Vec2s as parameters (or worse, alter Vec2s taken as parameters), which require other tricks to deal with.

thanks for the insights. solution 2 sounds reasonable to me too. Imho a thread-safe object pool could only be a possibility if you can use some third-party implementation.

Something else:
I'm not an expert on Java performance. What do you guys think about articles like http://www.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends which basically state that trying to avoid allocations is not worth the work in new JVMs?

Ooh, you shouldn't have gotten me started on that one: that article is complete and utter...umm, in the spirit of keeping this forum relatively clean and civil, let's say garbage.

Basically, although some of the theory behind that article is valid, the specific advice entirely misleading, often cited, and was written based on way too much wishful thinking about the current state of JVMs - the author should really know better than to give authoritative performance advice based on early beta builds with highly experimental features that might be pulled! If you use a normal JVM and do some tests today, you can see for yourself that his advice is flat out wrong, and garbage (or allocation - it's not clear what exactly is to blame) most definitely does still matter - pure vector math performed with temporary objects allocated each time runs 2-4 times slower than the equivalent math performed with only floating point ops, and while I don't remember the exact numbers, there's a fair improvement when you reuse a private static temp object instead of creating new ones. That's not to say that today's JVMs aren't extremely good, they are, but they're not perfect and if we care about performance we need to take that into account.

Don't take my word for it, though, it's easy to write some tests yourself and check.

That article explicitly says "JVMs can use a technique called escape analysis, by which they can tell that certain objects remain confined to a single thread for their entire lifetime, and that lifetime is bounded by the lifetime of a given stack frame." Which would have been really nice, if it was true about any JVM that was released and on people's computers.

Unfortunately Sun decided it was too tough to get right, and stripped it altogether from the early Java 6 VMs; scalar replacement has only recently started showing up in 6u14 betas (it's still not in a release VM), and the ruling from on high is now that stack allocation is not worth the effort (which my cynical side reads as "It's hard and we won't put enough manpower behind the JVM to do it."). And we're now four years after that article was written, advising people not to worry about it because it's "fixed" already!

Furthermore, it's now looking clearer and clearer that these optimizations will never make it into the client JVM, and since the main engineer on the tiered VM sadly passed away, that project is probably never going to happen, either, so long story short - don't hold your breath on any of this ever helping game performance unless you're willing and able to bundle an entire beta server JVM with your game. At least until control of Java is snatched away from Sun, that is...(given that Sun is up for acquisition by IBM, that's looking more and more possible now).

So yeah...that article gives some very wrong performance advice. "Go ahead, make a mess" is exactly the last thing you want to do if you have performance issues. I really wish people from Sun would say something other than "There is no performance issue" when asked to give performance tuning advice, it would make things a lot easier on us...

hehe, that's very interesting, I just hope I didn't spoil your day
In earlier projects I made experiences confirming your statements, object creation count simply does matter...
May I ask what you use for profiling? A few years ago I tested the Eclipse Test & Performance Tools Platform (TPTP) but I was not totally content. Later I worked with the YourKit profiler, which was nice but not for free.

I've had less than perfect experiences with TPTP, especially lately, to the point where it wouldn't even install on my current Eclipse installation. I've never tried YourKit.

When I'm using OS X, I always use Shark, which attaches to any Java process launched with the correct VM parameter - it's the only way to profile at all on OS X, as far as I know. On Windows, I've found the Netbeans profiler to be solid, though I haven't used it a whole lot. It's always better to profile on Windows than OS X, though, because more people use Windows JVMs, and JVMs have wildly different performance characteristics across operating systems (esp. on the Mac, which isn't developed by Sun). Sometimes I'll make a change that helps a lot in OS X only to discover that it slows things down in Windows. Graphical and threading issues are the worst offenders there.

I like profilers and find them very useful for some tasks, but honestly, most of the timing tests that I do I usually do in code by manually timing runs, especially if I've already discovered roughly where the bottlenecks are and I want to see if my changes are helping. For instance, for JBox2d I'll create a world that stresses a lot of different parts of the code (i.e. has some circles, some polygons, some joints, some CCD, etc.) and doesn't go to sleep, and see how long it takes to simulate a certain number of frames. If it runs faster with a change, then it was worth it, if not, then I roll it back. Sometimes what does and doesn't help is counter-intuitive, so it does help to check (one exception: getting rid of allocations seems to always help, at least in my experience, so I don't even bother checking those optimizations anymore).

Yes, I heard that NetBeans has a decent profiler too. Since I'm working on windows it's gonna be one of these two (although I more and more consider Vista a pretty effective advertisement for Macs).
When I start the profiling and optimizing sessions I will keep you updated. Thanks a lot for sharing your wisdom and the effort you put into JBox2D (that goes out to all contributors).

Anyone managed to bind Textures to shapes? I've been trying with ProcessingDebugDraw's method drawImage but there will always be a problem with the offset of the image.

Macs are great in many ways, but to be perfectly honest, I've been a little disappointed for development purposes - for Java, it's fine (apart from the fact that the JVM is not the same so you never really know what a Windows person will see), but for other stuff (C++ is the one that I need a lot of and can't do very well in OS X) it gets real tough. I find myself booting XP for work a lot more than I would like in order to code C++!


Hmm, there's an example in the testbed that does this usig ProcessingDebugDraw, but I haven't used it much outside of that, so it's very possible that it's either unclear or buggy. Can you post some code, and maybe I can help?

You might check to see if you're rendering based on "getLocalPoint()" vs. "getPosition()" as the former is the center of mass and might not be what you expect if your shapes are "off center" from the body's position.

Bill