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%."
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%."
The real problem was actually... (Score:4, Interesting)
Re: The real problem was actually... (Score:1)
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.
Re: The real problem was actually... (Score:2, Interesting)
You're one of those people who see "assembly" in the term "webassembly" and think it means downloading executables and running them outside the browser sandbox.
You are incorrect. Webassembly has no capabilities that JavaScript does not - so it's not any more a risk.
If anything it's going to mean safer code because you write in high level first class languages with first class tooling which is then compiled to webassembly.
Re:The real problem was actually... (Score:5, Interesting)
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).
Re: (Score:2)
I'm not sure, but I think you're talking about licensing. What I said applies to paid, free, and 'libre' software. Software-in-a-browser is a service, one that typically comes with subscription fees and constant, workflow-breaking churn for users.
We don't know how to code, so we just throw things (Score:2, Insightful)
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
Re: (Score:1)
Would you prefer inability to use an application at all because it hasn't yet been ported to your device's operating system?
Re: (Score:3)
But there have to be enough people sending money to the developer in order to cover the cost of time and materials to make a port. In the case of minority desktop operating systems, such as macOS, X11/Linux, and FreeBSD, this isn't a sure thing.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
Like I said, this was an order of preference. If I'm going to depend on a tool, i want it to be there until I no longer have use for it. SaaS is ephemeral at best.
Free web app with paid native client (Score:2)
So you prefer 1 or 2 over 3 or 4. Would you still prefer such even if 1 or 2 were paywalled and 4 were without charge?
It's a misleading article... (Score:1)
Re: (Score:3)
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
Re: (Score:2, Informative)
Yes, but C is significantly faster than C++, and uses a smaller memory footprint.
A good point except no it isn't. I use C++ to program ATTiny85s. A generous 512 bytes of RAM. You can target even smaller with g++, all the way down to 32 bytes. C++ uses no more memory than C.
Re: (Score:2)
Re: (Score:2)
How fast can Ada go?
Probably similar but a bit slower. It's got more or less the same world model with mapping to the same structures with the same low level types and no significant runtime costs. Probably slower because there's an implication of more runtime checking of correctness.
Re: (Score:3, Informative)
You're half right. Only C is the fastest, and only if you avoid error checking.
No it isn't.
C++ has a lot of overhead in the runtime, especially in regards to error and sanity checking. It's slower than C.
No. Most code doesn't incur runtime costs. The language features that use the runtime are:
1. Virtual functions. These incur a double pointer indirection as compared to a single indirection for a function pointer. If you have lots of objects with many virtual methods (like the VFS layer in Linux) and a high
C++ is indeed inefficient (Score:2)
Because it uses reference counting for garbage collection. Experiments long ago show that modern generational garbage collection is much more efficient. It also does not suffer from the cycle problem.
C++ is also slow because it does not automatically inline commonly used functions between modules. Programmers often miss these which makes it slow in practice.
C++ is also slow because it is precompiled. This means that it is normally only compiled for a fairly generic instruction sets in order to minimize
Re: (Score:2)
Because it uses reference counting for garbage collection. Experiments long ago show that modern generational garbage collection is much more efficient.
This is one of those things that might look sort of superficially right on the surface but actually wrong in practice on an awful lot of levels and misses a lot of things.
C++ doesn't "use" reference counting for garbage collection. C++ provides a reference counted type you can use if you like. The thing is most C++ code simply doesn't create any garbage so
Re: (Score:2)
The simple cases of say a string built up in a procedure and then not used again are optimized away. Java since 1.6 (2006) (and presumably .Net) also expand objects when declared as local variables. No garbage. And their aggressive in lining means that no more garbage should be created than for a C++ program.
You're confusing inlining and escape analysis. For java to be able to stack allocate (and deallocate) variables, it has to be able to prove that no reference is ever taken that outlives the scope. For C
Re: (Score:2)
By doing away completely with the HTML5-OS-running inner-platform effect of a virtual machine
There has to be some sort of inner platform in order to run one program on multiple instruction sets and windowing systems. Wikipedia's article about inner platforms specifically mentions portability as a case where it is not an anti-pattern.
Cross-testing (Score:2)
Cross-compilation and an industry standard API like POSIX.
First, POSIX has no GUI layer. X Window System exists, but only one of the five major client operating system families ships it.
Second, cross-compilation doesn't make it any easier for an application developer to cross-test the application to ensure that it is free of defects before distributing the application to the public or submitting the application to an app store owner for review.
That's a nice way to say... (Score:3)
Nice way to say that EBay's JavaScript developers are writing code that runs 50x slower than it has to.
Re: (Score:1)
Show me on the doll where the Javascript coder touched you...
And the conceptual difference between web assembly (Score:1)
running on a virtual machine and a JVM is....?
Answers on a postcard.
Re-invention of the wheel #435.
Re: (Score:1)
The JVM is unsuitable for high-performance code. The web-assembly stack machine (no, it is not a "VM") is optimized for performance.
Re: (Score:2)
"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"
Re: (Score:2)
The authors want a marketing-compatible term, no matter whether it is correct or not. A stack machine is not a VM.
Re: (Score:2)
It is if it emulates a CPU in software FFS.
Re: (Score:2)
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"?
Re: (Score:2)
You don't think bank trading systems need to be fast?
Re: (Score:2)
Apparently you have no idea what a VM is.
Re: (Score:2)
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.
Re: (Score:2)
A CPU is hardware - ie its a real machine. This is software, hence *virtual* machine. Get a fucking clue.
Re: (Score:3)
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).
Re: (Score:2)
Wasm lacks One Rich American Called Larry Ellison (Score:3)
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.
Absolutely nothing "astonishing" here (Score:1, Flamebait)
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.
Re: (Score:2)
Indeed. What a waste.
Plus the very real threat WebASM has... (Score:1)
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
Fast isn't everything (Score:5, Insightful)
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.
Nor is the CPU the only power draw (Score:2)
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.
Power usage isn't a function of # active threads (Score:2)
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
Re: (Score:2)
" 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
Async or Wasm? (Score:3)
So it was faster because they hedged and used async to scan? What does that have to do with WebAssembly?
Rube Goldberg programming (Score:3)
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.
Strawman (Score:3)
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.
Rust (Score:2)
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
Re: (Score:2)
Everything has stopped working she says. (Score:1)
"I'm tearing my hair out trying to get it to do what was formerly so easy," says my wife the eBay user.