Resources | Resources |



Performance considerations

To improve performance, developers may want to choose interfaces based on zero-initialization options and the need to find the heap.

Zero-initialization (ZI)

By default, Brew MP allocates memory in zero-initialized blocks. If an application needs a large block of memory, the effect on performance from zero-initializing the block can be substantial. For example, most of the time spent allocating a 1MB block of memory for an application is taken up in writing zeros to all of the bytes in the block.

If an application is going to fill the block entirely (for example, by storing a buffer, drawing an image, or receiving data off the network), then there is no advantage in filling the block with zeroes that will be rewritten. However, for allocating a structure or an array of pointers, there is an advantage in zero-initializing all the fields in the structure to protect against uninitialized pointers that can result in the device crashing.

To skip zero-initialization in the application-layer interfaces, use the flag ALLOC_NO_ZMEM=1. IEnv and IHeap1 provide NoZI functions that do not zero-initialize. The function names end with "NoZI".

Locating an application's heap

With IEnv functions, the heap is stored in the application's context in the Env. These functions always access the same heap for a given Env.

However, the application-layer functions and legacy Brew APIs may access different heaps depending on how they are called. Because they do not receive a pointer to the heap, they must first invoke a mechanism to find the heap of the calling application, which can impact application performance.

Similarly, OEM_Malloc(), OEM_Realloc(), and OEM_Free() must call AEEHeap_GetGroupHeap() to find the system heap, potentially affecting application performance.

Developers can use IEnv on the system heap and get the same result, usually more quickly.