dominates resource use, see one to two order of magnitude runtime performance improvements. Memory use Java memory use is much higher than C++'s memory use because: There is an overhead of 8 bytes for each object and 12 bytes for each array in Java. If the size of an object is not a multiple of 8 bytes, it is rounded up to next multiple of 8. This means an object holding one byte field occupies 16 bytes and needs a 4-byte reference. C++ also allocates a pointer (usually 4 or 8 bytes) for every object which class directly or indirectly declares virtual functions. Lack of address arithmetic makes creating memory-efficient containers, such as tightly spaced structures and XOR linked lists, currently impossible (the OpenJDK Valhalla project aims to mitigate these issues, though it does not aim to introduce pointer arithmetic; this cannot be done in a garbage collected environment). Contrary to malloc and new, the average performance overhead of garbage collection asymptotically nears zero (more accurately, one CPU cycle) as the heap size increases. Parts of the Java Class Library must load before program execution (at least the classes used within a program). This leads to a significant memory overhead for small applications. Both the Java binary and native recompilations will typically be in memory. The virtual machine uses substantial memory. In Java, a composite object (class A which uses instances of B and C) is created using references to allocated instances of B and C. In C++ the memory and performance cost of these types of references can be avoided when the instance of B and/or C exists within A. In most cases a C++ application will consume less memory than an equivalent Java application due to the large overhead of Java's virtual machine, class loading and automatic memory resizing. For programs in which memory is a critical factor for choosing between languages and runtime environments, a cost/benefit analysis is needed. Trigonometric functions Performance of trigonometric functions is bad compared to C, because Java has strict specifications for the results of mathematical operations, which may not correspond to the underlying hardware implementation. On the x87 floating point subset, Java since 1.4 does argument reduction for sin and cos in software, causing a big performance hit for values outside the range. Java Native Interface The Java Native Interface invokes a high overhead, making it costly to cross the boundary between