1.4.1 Memory footprint | JAVA 3D Programming | Chapter 1

1.4.1 Memory footprint

Java programs generally tend to require more memory than native programs. This is especially true of programs with a GUI using Swing/JFC. Java 3D can also have high memory requirements, especially if your application loads lots of large bitmaps for texture mapping objects, or defines complex geometry composed of many thousands of vertices.

To give you some idea of Java 3D’s memory requirements, table 1.1 shows the total memory required for the Java 3D Fly−Through application. As you can see, bringing up the Swing application requires 25 MB, while opening the city scene pushes memory usage up to over 100 MB.

Table 1.1 Java 3D Fly−Through statistics

Working set	25 MB (no scene loaded)
Working set	108 MB (city scene loaded)

Memory usage will be an important component of your application performance. Performance will be extremely poor if your target users have less physical RAM available than the working set for your application. In this case, the operating system will have to page virtual memory to and from disk.

Another performance criterion that can be important for some applications is startup time. You should set targets for the startup time for your application. The JVM can take a considerable time to start, especially on slower machines with limited RAM. In addition, if you are loading large texture files or 3D object models, your startup time can become very significant. The RAM footprint of your application (including the JVM) and the available system RAM of the end user’s computer are the most significant elements affecting startup time. You should take regular startup time measurements while you are in development to ensure that your end users are not frustrated every time they launch your application.

If you are deploying an applet, you should also be aware of the time required for it to download, as well as the graphics resources the applet requires for rendering. Texture images and 3D models can quickly become very large, so some download time targets based on typical end user bandwidth will also prove very useful.

As a reference, I measured the startup time of the Java 3D Fly−Through application. As you can see in table 1.2, launching the application took a very respectable 3 seconds, while loading the 3D content took 14 seconds. Fourteen seconds is a long time, and necessitates some form of progress indicator to reassure users that progress is occurring!

Table 1.2 Java 3D Fly−Through statistics

Start−up time	3 seconds
Loading city scene	14 seconds