Introduction

We all know Salesforce is a resource constrained environment. As a Software Engineer who's spent most of my career working in Salesforce orgs, I can say I've been left wanting for performance from time to time. This is where WebAssembly comes into play... WebAssembly, or wasm as it's commonly referred to, is to the browser, what assembly is to your computer or a microcontroller. The performance gains and pitfalls associated with using wasm with JS are well documented, but Salesforce has a lot of idiosyncrasies. Can WebAssembly be used with Salesforce Lightning Web Components? If so, would there be meaningful performance gains? Will the Locker Service cause problems? These are the questions I wanted to answer. Not because I think it'll be broadly useful, but because I have, on occasion been left wanting for performance when writing Lightning Web Components.

In this post, I will share the resources I used to prove that wasm can be used with Lightning Web Components, and that the performance gains are significant enough to be considered a viable option for solving problems that can come into play when you're processing large amounts of data or need to do something math heavy.

Target Audience

If you're a Salesforce developer who's worked a fair bit with Lightning Web Components, don't mind learning about, or have a passing familiarity with Rust and Cargo, you'll find this relatively easy to follow and shouldn't have much, if any trouble replicating my results on your own or deploying the source I provide. If you're not that person, and find this topic interesting, please don't be afraid to continue reading, I just won't be focusing on the tools or the Rust language as I'd like to keep this content short enough to read without losing the your attention. If you can deploy to an org using a package.xml, you will be able to get this work into your org and run the tests yourself.

Assumptions I Make About You

• You know how to checkout a git repository from GitLab.
• You know how to deploy to a Salesforce org.
• You know how to work with Salesforce Static Resources.
• You are willing to read the instructions in the ReadMe if you want to play with this yourself.

So, What is WebAssembly (wasm) anyway?

WebAssembly (Wasm) is a technology that allows code written in languages like Rust, C, and C++ to run efficiently in web browsers. It achieves near-native execution speeds, making it ideal for performance-intensive tasks such as games, data visualization, and image processing. As Salesforce Developers, it's data visualization we're probably going to be interested in, but I can see it being helpful when user input requires large amounts of data to be processed, reordered, etc... Maybe we need to crunch a bunch of numbers, or process a bunch of data before the component renders.

Why Choose Rust?

I chose Rust because I like it and It's seeing wide industry adoption. According to The Register Microsoft is rewriting core features with Rust, and they arent alone. DARPA (Defense Advanced Research Projects Agency) is looking for proposals on how to efficiently move from C to Rust for the United States government. Why? because of its memory safety features.

Variables in Rust are immutable by default and Rust uses a Borrow Checker. The Borrow Checker ensures that references do not outlive the data they point to, preventing dangling references (aka the dangling pointer). It also enforces rules around mutable and immutable references, ensuring that data is accessed safely. If you'd like to know more about the borrow checker, the Rust documentation does a better job than I could ever hope to describing it.

The Hypothesis

WebAssembly compiled from Rust can be used with Salesforce Lightning Web Components. The main reason I wasn't sure this would work is because of how the Locker Service meddles with your use of common browser objects and apis. if you've been working with Lightning for a while, you've probably been bitten by the Locker Service before. While many its annoyances are solved with Lightning Web Security, most orgs are still using Locker as those created prior to the Winter '23 release default to Locker and I doubt a significant portion of them have made the switch. I wanted to prove it could be done and that the pattern could effectively improve performance under compute heavy conditions.

Testing Methodology

Three functions were implemented in JS and Rust keeping them as close to equal as I could muster. String processing, array manipulation, and math computation.

String Processing

This test generates a 10000 character string, then reverses it.

JavaScript Implementation

    stringProcessingTest_JS(){
        let str = '';
        for (let i = 0; i < 100000; i++) {
            str += 'a';
        }
        str = str.split('').reverse().join('');
        return str;
    }

Rust Implementation

pub fn string_processing() -> String {
    let mut str = String::new();
    for _ in 0..100000 {
        str.push('a');
    }
    str.chars().rev().collect()
}

Array Manipulation

This test creates an array of 1000000 values, creates a new array where each value is multiplied by 2, then filters it down to values divisible by 3 before reducing to a single value representing the sum of all elements.

JavaScript Implementation

    arrayManipulationTest_JS(){
        let arr = [];
        for (let i = 0; i < 1000000; i++) {
            arr.push(i);
        }
        arr = arr.map(x => x * 2);
        arr = arr.filter(x => x % 3 === 0);
        return arr.reduce((acc, val) => acc + val, 0);
    }

Rust Implementation

pub fn array_manipulation() -> i32 {
    let mut arr: Vec<i32> = (0..1000000).collect();
    arr = arr.iter().map(|&x| x * 2).collect();
    arr = arr.into_iter().filter(|&x| x % 3 == 0).collect();
    arr.iter().sum()
}

Math Computation

JavaScript Implementation

    mathComputationTest_JS(){
        let result = 0;
        for (let i = 0; i < 1000000; i++) {
            result += Math.sqrt(i) * Math.sin(i) * Math.cos(i);
        }
        return result;
    }

Rust Implementation

pub fn math_computations() -> f64 {
    let mut result = 0.0;
    for i in 0..1000000 {
        result += (i as f64).sqrt() * (i as f64).sin() * (i as f64).cos();
    }
    result
}

For this set of tests, I just wanted to test pure execution speed including overhead introduced by the JS bindings. This isolates the behaviour I want to test, but does not account for passing data into WebAssembly. I expect this would impact performance to some extent, and I plan to test that among other things in a followup post. I didn't include it here, because the documentation suggests there are some gotchas, and I'm a fan of the point particle approach to problem solving. These tests represent my point particle, and I'll be adding complexity in a follow-up post.

Test Execution

The following function is run when clicking the Run Test Suite button is clicked. Before any tests are run, a token load is applied to the processor in the form of running all tests 10 times to make sure boosting does not impact the captured execution time of the first test case. Start and end times are captured immediately before and after the code being tested is executed.

executeAllTests(){

        this.data = [];
        let runResult;
        let totalRuntime = 0;
        let runTimes = [];
        let runTime = 0;

        //Sacrificial tests.  This makes sure your cpu is spun up.
        for(let i = 0; i < 10; i++){
           this.arrayManipulationTest_JS();
            this.mathComputationTest_JS();
            this.stringProcessingTest_JS();
            array_manipulation();
            math_computations();
            string_processing();
            run_test_suite();
            run_test_suite_extended();
       }

        //Run JS performance tests
        for(let i = 0; i < 10; i++){
            const startTime = performance.now();
            this.arrayManipulationTest_JS();
            this.mathComputationTest_JS();
            this.stringProcessingTest_JS();
            const endTime = performance.now();
            runTime = endTime - startTime;
            runTimes.push(runTime);
            totalRuntime += runTime;
        }
        runResult = this.buildRunResult('Profile JS', runTimes, totalRuntime);
        this.data = [...this.data, runResult];

        //Run wasm performance test where each function is called individually
        totalRuntime = 0;
        runTimes = [];
        for(let i = 0; i < 10; i++){
            const startTime = performance.now();
            array_manipulation();
            math_computations();
            string_processing();
            const endTime = performance.now();
            runTime = endTime - startTime;
            runTimes.push(runTime);
            totalRuntime += runTime;
        }
        runResult = this.buildRunResult('Profile WASM Multi Call', runTimes, totalRuntime);
        this.data = [...this.data, runResult];

        //Run wasm performance test where a single call to wasm is used to run all three tests
        totalRuntime = 0;
        runTimes = [];
        for(let i = 0; i < 10; i++){
            const startTime = performance.now();
            run_test_suite();
            const endTime = performance.now();
            runTime = endTime - startTime;
            runTimes.push(runTime);
            totalRuntime += runTime;
        }
        runResult = this.buildRunResult('Profile WASM Single Call', runTimes, totalRuntime);
        this.data = [...this.data, runResult];

        //Run wasm performance test where a single call to wasm runs all test for _ .. 10
        totalRuntime = 0;
        runTimes = [];
        for(let i = 0; i < 10; i++){
            const startTime = performance.now();
            run_test_suite_extended();
            const endTime = performance.now();
            runTime = endTime - startTime;
            runTimes.push(runTime);
            totalRuntime += runTime;
        }
        runResult = this.buildRunResult('Profile WASM Extended', runTimes, totalRuntime);
        this.data = [...this.data, runResult];
    }

Modifications to Generated Bindings

The bindings generated by wasm-bindgen were not locker compliant. So, I had to make a few changes before my Lightning Web Component would load. All bound Rust functions were updated as shown below and exported as named exports at the bottom of the file with everything else.

export function array_manipulation() {
    const ret = wasm.array_manipulation();
    return ret;
}

//^^ was changed to:
function array_manipulation() {
    const ret = wasm.array_manipulation();
    return ret;
}

At the bottom of the file, I changed the default export to a named export adding each of the Rust bindings.

export { initSync };
export default __wbg_init;

//^^ was changed to include the new named exports.
export { initSync, __wbg_init, run_test_suite, array_manipulation, math_computations, string_processing, run_test_suite_with_extended };

Finally, there was a single block of JS in the async initialization script that didn't play well with locker due to an unsupported use of import. This block had to be removed, and did not have any impact on my ability to continue. The path to the wasm module as a static resource is passed into the __wbg_init function, so this is erroneous code anyway. wasm-bindgen doesn't know about the locker service and so, it doesn't account for it's browser api restrictions.

    if (typeof module_or_path === 'undefined') { //This block was removed
        module_or_path = new URL('wasm_perf_tests_bg.wasm', import.meta.url);
    }

To account for the case where a path was not provided, I added an else block to the preceeding if block:

    if (typeof module_or_path !== 'undefined') {
        if (Object.getPrototypeOf(module_or_path) === Object.prototype) {
            ({module_or_path} = module_or_path)
        } else {
            console.warn('using deprecated parameters for the initialization function; pass a single object instead')
        }
    }else{ //Added this
        console.error("Don't forget to pass the static resource path into __wbg_init()")
    }

Test Results

I shared my initial results in LinkedIn prior to writing this article because what I observed was exciting. I've updated my Lightning Web Component in a few ways since that snippet was shared

1. I run all tests once without profiling to make sure the CPU is spun up.
2. I traded single buttons with execution time in mS under them for a table.
3. I run each test case 10 times
4. The set of execution times for each test case are displayed in a table with the average execution time, and variance.

The following snippet shows a test run in my org. If you deploy this work to your org, you might get different times. That's ok. What's important is the difference in execution time between test cases. All execution times are still in mS.

Conclusion

These test results clearly demonstrate that integrating WebAssembly with Salesforce Lightning Web Components can lead to significant performance improvements. It's clear that while the difference is not enough to really notice for the average business case, making a call to wasm does incur significant overhead relative to execution time. It is therefore a good idea to keep your api surface as small as possible. Doing so will keep that overhead to a minimum and maximize the gains you can achieve using wasm.

Where Can I Get the Source?

The source for this experiment can be cloned or forked from https://gitlab.com/BitWizrd/wasm-salesforce. I've included some instructions in the README. If you have any questions, or would like to chat on this topic, I'd love to hear from you. Feel free to message me on LinkedIn.

Resources I Found Helpful

• The in depth Blog Post by Surma did a great job bringing me up from nothing as far as compiling Rust to WebAssembly goes. He doesn't start by telling you to just use the tools someone else built. He brings you up from the bottom of the chain so you understand what's going on under the hood and where the gotchas are. I've bookmarked it for later reference should I run into any issues later. I can't recommend it enough.
• The Mozilla documentation was great for inspecting the generated JS bindings and understanding what everything is doing. With this documentation, you could (and I would argue should at least once) write your bindings manually including the JS required to instantiate and initialize your WebAssembly.
• If you've never seen Rust before, it's principles of operation are a bit different. You'll have an easier time if you've written C/C++ in the past, but you'll want to understand why data is immutable by default and how the borrow checker works or risk going mad. I used The Book, but you can try The Rustlings Course, or Rust By Example if either of those styles work better for you.