Best practices

While the SDK API is quite straight forward, there are some common patterns that are good to know about to ensure optimal performance and usage.

Use one instance of the SDK at a time

While there is nothing technically preventing instantiating multiple instances of the SDK, doing so will likely degrade performance drastically. The key lifecycle methods of the SDK are synchronous, and will block the process execution until they are completed. Especially the .waitForData() method, which can block the process for the specified millisecond value if it has to wait for SDK data. Two separate instances of the SDK waiting for data can push your application over the maximum "process time" of 16ms that iRacing provides for SDK consumers, which could cause undefined behaviour.

Additionally the native instances do not share any state, meaning all work will have to be duplicated.

Cache the data you need at the beginning of your data loop

There is a lot of data coming from the iRacing SDK, and consuming that data can be complex. For example, the session data is exposed as a string of yaml -- internally this gets parsed and converted into a javascript object for you to use, which is a complex and time consuming operation. The wrapper class attempts to cache this based on a data version number provided by the SDK, that way if the data has not changed no yaml parsing needs to be done and the current data can be re-used. When consuming this data in real-time it is possible that the data version can change while you are still processing, which would cause a subsequent call to .getSessionData() to have to fetch and parse a large yaml file in the middle of your frame, which is very bad for performance.

Telemetry is a similar story -- by default the API in the SDK is optimised for obtaining a single telemetry value at a time, and the helper function .getTelemetry() must do a lot of work to build out the full telemetry object. As this object is guaranteed to change every update tick, it is not cached internally meaning each call to .getTelemetry() will re-build the full telemetry object. To optimise this, there are some options:

• If you only need a small handful of telemetry variables, cache them independently via .getTelemetryVariable() at the top of your update function.
• If you need a large number of telemetry variables, cache .getTelemetry() at the top of your update function. This prevents performance losses due to passing excessive data calls between node.js and C++.

const sdk = new IRacingSDK();

function loop() {
    if (sdk.waitForData(16)) {
        // Cache necessary data so they can be re-used.
        const sessionData = sdk.getSessionData();
        const telemetry = sdk.getTelemetry();

        // do something with the data...
    }

    setImmediate(loop);
}

loop();