Why people here suggest very often only low level optimizations?

Performance Tuning
#1

Maybe you find my question a bit naive but when I look the title of the topics in this section, it deals with JVM memory allocation, allocation on the stack, garbage collection, v-sync, final modifier… only “low-level” optimizations… Why?

I have 2 other questions:

  • Do you think that low-level optimizations can improve the performance better than high-level optimizations?
  • Do you think that we should begin with high-level optimizations and after that low-level optimizations in a project?
    On my view, it is better to work on higher-level optimizations, algorithmic improvements before going closer to lower layers and I assume that we often can improve the performance better with high-level optimizations, it depends on where we start.
#2

Maybe people ask the questions after they did the high level optimalisations…

#3

High level optimisations like algorithmic ones tend to be already well understood and documented (as well as being non-java specific). The VM on the other hand tends to be a complicated black box often with strange quirks and non-intuitive behaviour, which is why it gets most of the performance questions IMHO.

#4

It is often true but it was difficult for me to find a detailed explanation of the cells-and-portals algorithm (most papers about it were really abstract and very lacking clarity) whereas it is easy to find some information about BSP trees, quad trees, octrees…

Perhaps you’re right but why do you assume it? Maybe I should ask programmers here if they really did high level optimizations.

#5

Low level optimizations are insofar interesting that they are very isolated and thus it’s easy to test/bench and reuse it elsewhere.

High level optimizations on the other hand require a rather deep understanding of the problem domain. It’s often pretty difficult to explain the issue at hand in a brief fashion. And if you can, it’s a well known scenario and you already found the answers you were looking for with the help of search engines. E.g. path finding or using a broad collision detection phase prior to more accurate checks and the like. (If the vocabulary exits there are solutions.)

So, while high level optimizations typically yield far bigger gains, talking about them often isn’t a viable option.

#6

- Do you think that low-level optimizations can improve the performance better than high-level optimizations?
You’re not going to find the first 10 million prime numbers with a brute force algorithm just by replacing ++ with +=2.
But you’re also not going to gain any performance by using dirty rectangles when the entire screen changes each frame.

Sometimes, low-level optimizations are all you’ve got.

- Do you think that we should begin with high-level optimizations and after that low-level optimizations in a project?

That totally depends. High-level optimizations can be hard to add later on, so it’s usually a good idea to implement them straight away. But on the other hand, I’m a strong believer in only adding code you actually USE, so don’t add fancy BSP type algorithms until your game has more than a single large rectangular room.
IMHO, it’s better to rewrite code to add new functionality (it gives you a nice reason to clean up your code anyway) than to write too much code from the start, locking yourself into a bad design.
This is only true for projects with two or less programmers, though. If you’ve got more than that, solid design from the start is much more important.

Low-level optimization, on the other hand, should NEVER be added unless you absolutely have to. It’s the opposite of clean code, it’s highly specialized code trying to solve a very specific problem acting under very specific assumptions. It basically moves the code in the opposite direction as what I suggested above (start specialized, then broaden over time).

#7

I see what you mean. It explains why some programmers look only for low level optimizations, they can be applied in a lot of situations, they are easier to describe and it is easier to measure the gain of performance when using them.

#8

And they’re more fun! =D

#9

While agreeing with all the points made so far, I’d also add:

  • High level optimizations are usually domain specific, not programming language specific, which means there are far better places to ask the questions than a general Java game development forum (physics forums, graphics forums, etc.)

  • For better or worse, except for people writing games, most Java programmers don’t really care about shaving an extra 10-30% off their execution time, so most general Java programmers have not had to do much low level optimizing (hence general Java forums are not great places to look for this type of advice, so more people show up here)

  • It’s always considered good practice to pick good high level algorithms applicable to your problem domain; the low level stuff that actually helps, on the other hand, tends to be explicitly warned against in Java, and the strange JVM quirks that affect performance in various scenarios are rarely obvious, platform independent, or documented (and if they are, the documentation is difficult to find). So apart from word of mouth, it’s difficult to find good advice on low level optimization, whereas any textbook on a subject will help you figure out the high level design choices you need to make.

  • Eric

#10

Yeah, if people are using Java for their games in the first place then performance isn’t the reason they’re doing so. I think (at least from personal experience) the main reason people are using Java is because it’s a very fun and predictable language that is for the most part very well documented. There are a few places where things can get both more interesting and confusing, as well as unique. People using Java probably aren’t too worried about these easier speed changes because that’s not their reason for being here in the first place.

#11

I agree with you but the problem is that even many Java programmers think that Java is not a powerful language, I mean lots of them think Java is not a good tool if you’re looking for speed. Personally, I use Java both for its easiness and for its EXCELLENT cross-platform performance. When I see my frame rate on some recent machines, I realize that I break lots of prejudices against Java as a well fitted language for real time performance even though my engine is still slower than Java3D (less than twice slower) and JPCT (3 times slower in hardware accelerated mode).

#12

Yeah, at this point in Java’s lifetime I think that unless you’re trying to make a game that can squeeze absolutely every bit of speed out of a processor, you really don’t need to worry about it.