Skip to main content

Optimization best practices

|

This guide highlights key strategies to improve app performance and resource management when using the Magic Lane SDK for C++.

By following these best practices, you can create smoother user experiences, reduce unnecessary processing, and maintain efficient use of memory and system resources.

Minimize SDK method calls

Frequent calls to SDK methods, including getters, setters, and object constructors, can be computationally expensive and may lead to UI lag or degraded performance, especially in performance-critical paths such as rendering or user interactions.

In order to improve efficiency and avoid potential performance issues:

Cache static or infrequently changing values

For example, values like IDs, names, or other immutable properties should be retrieved once and stored locally. Repeatedly querying such values from the SDK can introduce unnecessary overhead. Identify which values can be cached and which values are often changing and need to be queried each time depending on your use case.

warning

Avoid retrieving a large number of elements all at once, as this can lead to increased memory usage and slower performance.

A more efficient approach may be, depending on your use case, to fetch values lazily - only when they are needed for the first time - and cache them for future use. This ensures optimal resource utilization while maintaining responsiveness.

Avoid repeated collection queries

When accessing a collection (such as lists of elements) from the SDK multiple times within a short scope, store the result in a temporary variable rather than calling the SDK method repeatedly.

Throttle or debounce rapid calls

Debouncing ensures that a function is executed only once after a specified delay, and only after the final event in a rapid sequence of interactions. This pattern is particularly useful in scenarios involving user interaction with elements such as text fields, buttons, sliders, or other dynamic UI components.

When such interactions trigger SDK method calls in quick succession, it can lead to performance issues or unnecessary processing. Instead, debounce these calls to ensure the SDK method is invoked only once, after a defined period of inactivity. This approach reduces redundant calls and improves overall application responsiveness.

Use the provided listeners to detect changes

Instead of polling the SDK to detect state changes (which generates repeated calls), register listeners provided by the SDK. This allows your code to react to changes only when they occur and avoids unnecessary calls to check the SDK state.

Lazy initialization and deferred loading

Initialize or load SDK objects when they are actually needed. Avoid early or unnecessary SDK calls during app startup or in unused paths. This approach can greatly improve the performance of the app startup time.

Request and redraw images only when the image id changes

The Image, AbstractGeometryImage, LaneImage, SignpostImage, and RoadInfoImage classes expose a getUid getter that uniquely identifies each image instance.

During navigation, it's possible for sequential NavigationInstruction objects to reference identical images. To optimize performance, avoid re-requesting or redrawing images if their uid matches those from the previous instruction.

Avoid calls to the SDK when UI animations are ongoing

To ensure smooth user experience and prevent potential performance issues, avoid making calls to the SDK while UI animations are in progress. These calls can introduce delays or cause stuttering in the animation rendering.

Whenever possible, schedule SDK calls to occur either before the animation starts or after it has fully completed. This approach helps maintain fluid animations and reduces the risk of dropped frames or UI lag.

Avoid the unnecessary creation of MapView objects

While multiple MapView objects can be used simultaneously, having a large number of them active at once may negatively impact performance.

To optimize, avoid maintaining a list of MapView instances. Also reuse a single map view object whenever possible rather than creating new ones on demand.