Focus on performance: Edge profiling

Introduction: Tuning is not always speed, sometimes need to adjust other aspects of the application, if the application needs tuning, the first thing to do is to use the profiler to monitor the application. However, profiling is not always feasible, and sometimes the reason may be ridiculous. In this installment of performance, Jack and Kirk talk about one of their recent experiences: they were instructed to dissect a fat client, which was actually so large that it did not leave room for profiling programs.

We have never experienced the problem of tuning application memory footprint. In general, the memory-related tuning requirements we see involve reducing the cost of garbage collection, ideally by resizing the heap or changing the garbage collection algorithm, and, if not, by using various techniques to reduce the amount of memory objects. However, sometimes the application takes up a lot of memory regardless of the efficiency of the allocation and garbage collection.

A trip to the weight loss Center

Recently, we were instructed to reduce the memory footprint of a fat client. Although the term "fat client" usually represents a common GUI client application, the client is almost obese. This client runs on a Windows platform with a maximum size of 2 GB. After removing the executable address space and the additional space required to introduce various JNI products, the maximum heap size that the application can use is approximately 1.2 GB or 1.3 GB. Unfortunately, some users have to instill large amounts of data into the application so that the space they occupy is often close to that limit. The most obvious tuning is to transfer to Unix machines, but is excluded because it is impractical-customers prefer to let the application lose weight.

So, our mission is settled. Analyze the FAT client to see what is taking up the space. Then lose weight on these objects, leaving room for future expansions or larger amounts of data. We think it's easy. It may take a while to reduce the number of objects that are usually not done overnight, but with such a large pile, there must be a lot of cellulite that can be cut off. We think so.

The usual process

We started the common memory footprint reduction process: setting up a test environment, providing a reproducible test, starting an profiler, running tests, analyzing data, and looking for tuning opportunities. Time goes by, we keep busy ... Or that's what we think. Now we're in the "Run Test" phase, and the profiler gets down. So we try again. It's dead again. We changed the profiler configuration to minimize overhead and try again. It's dead again. There is not enough JVM heap space to hold the profiler fully operational, let alone generate any useful profiling data. And we're using a good business profiling process that's generally reliable, so we're surprised.

Try again, try again.

It doesn't matter, there are countless fish in the sea, and now there are countless profiling procedures (see Resources for the latest review of profiling procedures). Another day, and the use of a profiling process, how? Unfortunately, the test process is strikingly similar. And the profiler is almost at the same point, and the second profiler crashes the JVM. Like a profiler, it can even do more configuration, reconfigure, reduce overhead, and remove more data. But it was just like an analytic program, and it crashed. Unfortunately, the third profiling process is no different.

Ingenious profiling procedures

However, there has been a subtle change in the fourth-number profiling process. A memory analysis of snapshots of surviving objects (ignoring object creation and garbage collection, only observing snapshots of surviving objects at a certain point), the fourth profiler did not increase the overhead of the JVM at all before requesting a snapshot. It worked! For the first time, our test passed the point where we needed to take a snapshot while the profiler was running. We are very happy. Then we activated the snapshot, and the JVM crashed.

We tried again, but the profiler needed too much extra space to generate snapshots. Can't work at all. We're back to the starting point! While there are half a dozen business profiling procedures to try, the result is obvious. You should do some lateral thinking.

Ironically, our problem is to dissect the complexity of the program itself. We need some kind of simple thing. Of course, simplicity does not mean low overhead, but since those complex profiling procedures disappoint us, try it. So we started scanning the open source profiling program.