Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming

Replacing JavaScript: How eBay Made a Web App 50x Faster With WebAssembly (techrepublic.com) 94

"Online marketplace eBay has revealed how it boosted performance of a demanding web app by 50x using WebAssembly," reports TechRepublic: The "astonishing" speed-up after switching from a JavaScript-based to a largely WebAssembly-based web app was detailed by the eBay engineering team, who say the performance boost helped make it possible to build a highly-accurate barcode scanner as a web app... a feature it offers in its Android and iOS apps to allow sellers to scan items they are auctioning. "WebAssembly was different. It has tremendous potential, we just did not have the right use case. Well, that changed recently," write the eBay software engineering team.

One of the advantages of WebAssembly (Wasm) is that it offers code portability for a variety of languages, allowing developers to take code they've written for other platforms and compile to WebAssembly so it can run in major web browsers. Consequently eBay was able to take the existing version of its barcode scanner written in C++ and compile that to Wasm using Emscripten, adopting the Docker and Node.js-based approach outlined here. After a few minor teething problems, the eBay team were able to run the barcode scanner in the browser, using a Worker thread and JavaScript glue code.

The Wasm-based scanner was able to process images of the barcode at 50 Frames per Second (FPS), compared to about 1FPS in an earlier JavaScript-based scanner eBay had tested, a speed-up the team described as "astonishing".

Unfortunately, the Wasm code only successfully completed scans 60% of the time, because it wasn't using the inbuilt APIs available for the C++ code to either autofocus or provide user tap focus for the center of the scanned object. eBay's team ultimately ended up implementing three separate worker threads running the Wasm code, the open-source barcode reader ZBar, and their original JavaScript-based scanner code.

"The winning response (i.e. the first one to send a valid barcode) is sent to the main thread, and all workers are terminated... With three threads racing against each other, the success rate was indeed close to 100%."
This discussion has been archived. No new comments can be posted.

Replacing JavaScript: How eBay Made a Web App 50x Faster With WebAssembly

Comments Filter:
  • by QuietLagoon ( 813062 ) on Saturday May 25, 2019 @10:44AM (#58652872)
    ... the misuse of the browser as the foundation for a slightly complex application, and not javascript.
    • by Anonymous Coward

      Well, I suppose it's nice to have better performing software, of course it probably depends (sorry) on the purpose of the application. Are you using wasm to speed up an app that is traditionally just fine in JavaScript? Why bother? Trying something different? Maybe. Trying to replace native apps? Might work for some situations but not all.

    • by epyT-R ( 613989 ) on Saturday May 25, 2019 @10:49AM (#58652904)

      The real intention of the programmable browser wasn't to build useful, efficient applications and make them available to people, it was to ensure control over distribution of said applications (and user data).

    • by Anonymous Coward

      This article seems way too exuberant about eBay's "brilliant idea" to race 3 implementations of a bar code reader against each other in separate threads, each doing the same job... How is that "boosting performance?" That sounds a lot more like wasting CPU cycles unnecessarily and increasing the heat output of everybody's computer to me.

      #LearnToCode

    • by tepples ( 727027 )

      Would you prefer inability to use an application at all because it hasn't yet been ported to your device's operating system?

      • }}} Would you prefer inability to use an application at all because it hasn't yet been ported to your device's operating system? {{{ --- that's a false dichotomy. I would prefer that the vendor writes a proper app for the operating systems on which the vendor supports the app. The web browser is just that, a web browser. It should not become an operating system.
        • by Trogre ( 513942 )

          In many cases a native port will never, ever, happen.

          While a browser should indeed not be an operating system, there are programs that are certainly more convenient to run in a temporary context with no installation, disk space, nor OS tweaks required.

          I'll just leave one example [classicreload.com] of an HTML canvas done well here. Have fun.

      • by epyT-R ( 613989 )

        Yes. In order of preference:

        1. native, well written/designed application written for the platform of choice, preferably with no skinning/theming, just standard widgets that conform to OS conventions.
        2. a decent port of an application that is still at least native for the hw and OS.
        3. a crappy virtualized version (eg java). I live with it until I can find a better replacement. These are often buggy and slow.
        4. 'web-app'. Even when they approach feature equivalency to real desktop solutions, they often come w

        • by tepples ( 727027 )

          In the case of options 1 and 2, you miss out unless and until such time as the developer becomes willing to begin to support your device's OS with a "native, well written/designed application" or "a decent port". Even if you are willing to pay, one customer alone isn't enough to fund a port.

  • They replaced a very specific feature. More that they wanted to implement a feature that was easier to port from native than to get it working correctly with js.
    • More that they wanted to implement a feature that was easier to port from native than to get it working correctly with js.

      No, I reckon it's going to be more or less impossible to get a pure JS one running as fast as a native one. JS is a much harder language to optimise than C++ and wasm by design maps easily to machine code.

      If someone's claiming that their language X is faster than C++, the correct response is "no it isn't". Remember Java? This year it's faster than C++, every year since 1998 (though the c

  • by reanjr ( 588767 ) on Saturday May 25, 2019 @10:53AM (#58652930) Homepage

    Nice way to say that EBay's JavaScript developers are writing code that runs 50x slower than it has to.

  • running on a virtual machine and a JVM is....?

    Answers on a postcard.

    Re-invention of the wheel #435.

    • by gweihir ( 88907 )

      The JVM is unsuitable for high-performance code. The web-assembly stack machine (no, it is not a "VM") is optimized for performance.

      • by Viol8 ( 599362 )

        "The JVM is unsuitable for high-performance code."

        I'm no fan of Java, but if its good enough to run multi gigabyte sized backend systems its good enough for a poxy little browser. JVMs have moved on since the 90s.

        "The web-assembly stack machine (no, it is not a "VM") "

        Its authors disagree:

        https://webassembly.org/ [webassembly.org]

        "WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine"

        • by gweihir ( 88907 )

          The authors want a marketing-compatible term, no matter whether it is correct or not. A stack machine is not a VM.

        • by gweihir ( 88907 )

          Also, there is a bit of a very fundamental difference between "high performance" and "large system". A bit of an _extreme_ fundamental difference. Do you really believe "large" implies "fast"?

      • by bws111 ( 1216812 )

        Apparently you have no idea what a VM is.

        • by gweihir ( 88907 )

          Apparently, you have no idea that basically all modern CPUs are stack machines or can be operated as stack machines. Hence there is no "V" here. Incidentally, that is why a stack machine was chosen for the wasm execution model. Apparently, you have no clue about that either. There is a translation layer, but it translates from stack-machine to stack-machine and usually it does it as JIT.

          • by Viol8 ( 599362 )

            A CPU is hardware - ie its a real machine. This is software, hence *virtual* machine. Get a fucking clue.

          • by bws111 ( 1216812 )

            So I was right, you have no idea what a VM is. None of that has anything to do with whether or not something is a VM. Webasm defines a machine, including instruction set, traps, etc. Code compiled for that machine does not execute on bare hardware. It is, by definition, a virtual machine. Like every other virtual machine (including those virtual machines that are exact copies of the hardware they run on).

            • What's more, no popular CPU is a stack machine. Every single CPU in popular use today is a register machine.
    • Subject: And the conceptual difference between web assembly

      running on a virtual machine and a JVM is....?

      The difference is lack of One Rich American Called Larry Ellison. Unlike with the Java platform, Oracle Corporation has no copyright claim to assert over WebAssembly.

  • Going from a so-so scripting language to C/C++ often gives a speed-up like that. The only people surprised by this are members of the current crop of incompetent coders that never used C, C++ or assembler.

    • by Anonymous Coward

      Of cpu exploits, like Spectre, Meltdown, etc thanks to direct instruction translations that make it easy to trigger CPU flaws from what is 'assumed' to be a safe browser instance, allowing them to circumvent multiple layers of false security and exploit or exfiltrate from the cpu cache directly.

      Scripting was always a bad idea, but it has gotten worse in recent years. Hell, it's now necessary to use javascript to work around flaws the security of html elements and even default resizing issues for presentatio

  • by RhettLivingston ( 544140 ) on Saturday May 25, 2019 @11:24AM (#58653116) Journal

    Presumably, this is written for a portable device with battery power. In this environment, speed isn't everything. Power usage is important too.

    Starting three separate threads to perform the same task and taking the output of the one that wins the race does is not a power-efficient solution. 2/3rds of the power is being wasted.

    This sounds like a unprofessional hack in every way.

    • Starting three separate threads to perform the same task and taking the output of the one that wins the race does is not a power-efficient solution.

      Your claim appears to assume that the CPU is the only or largest power draw. In my experience, it isn't necessarily the case. Even if faster processing causes the CPU to run hotter, it may still save power in other ways. First, the camera circuit doesn't need to be kept on as long in order to get a readable image. Second, the user completes the task sooner, which means the screen backlight and WLAN radio don't need to be kept on as long.

    • I have no idea where you got the idea that running three threads with the idea that only one will be successful will result in "2/3rds of the power is being wasted."

      First off, you are making the assumption that running three threads wasn't necessary to complete the task if you RFTA, you'll see that each thread provided a successful bar code scan in different cases. If you were only to run one thread, then at best, reads would be successful about 40% of the time. I imagine any kind of energy gains made in

    • " not a power-efficient solution"

      It is power efficient if on average you are ending the threads faster than you are increasing the power by running multiple threads.

      The summary doesn't show the relative figures for the middle speed thread, so let's construct a two thread example:

      Fast thread uses power Pfast and completes in time t but with a success rate of only 0.6
      Slow thread uses power Pslow and completes in time 50T with a success rate of 1.

      For 60% of the requests both threads are running but for only ti

  • by KidSock ( 150684 ) on Saturday May 25, 2019 @11:31AM (#58653138)

    So it was faster because they hedged and used async to scan? What does that have to do with WebAssembly?

  • by hackertourist ( 2202674 ) on Saturday May 25, 2019 @02:13PM (#58653978)

    Unfortunately, the Wasm code only successfully completed scans 60% of the time, because it wasn't using the inbuilt APIs available for the C++ code to either autofocus or provide user tap focus for the center of the scanned object

    it seems they were throwing a whole lot of resources trying to read fuzzy images of barcodes, instead of getting 1 good image. When an API to get good images was available already.

  • by Tough Love ( 215404 ) on Saturday May 25, 2019 @02:42PM (#58654116)

    Strawman article. Take a super crappy starting application to use as a punching bag and end by declaring omglulz webassembly no it really isn't javascript honest its something so much more amazing is so omglulz fast! And so the crap self adoring javascript culture shuffles on to eat more brains.

  • by Tom ( 822 )

    WebAssembly is incredible and was the primary reason I settled on Rust as the next programming language to learn.

    I've since re-written some simulation code in Rust that is now so fast that I can run it in the browser instead of having to run it on the backend, storing the results in a database and handing the client a flag he can use to retrieve the data after a waiting period.

    I've never been a fan of JavaScript, that abomination and its error-prone eco-system. WebAssembly has the potential of making a huge

  • Comment removed based on user account deletion
  • "I'm tearing my hair out trying to get it to do what was formerly so easy," says my wife the eBay user.

If all else fails, lower your standards.

Working...