5 ms·

PSPDFKit CTO here: We've been using WebAssembly since 2017 to render PDF documents directly in the browser and strongly believe in the future of the technology.

PSPDFKit CTO here: We've been using WebAssembly since 2017 to render PDF documents directly in the browser and strongly believe in the future of the technology. We published this benchmark to have a public indicator of the performance gains WebAssembly promises in a real-world product.

SXX 8y ago
Any chance you also benchmarked WA version against native code? What are results in your case?
- steipete 8y ago
  We did that in https://pspdfkit.com/blog/2017/webassembly-a-new-hope/ https://pspdfkit.com/blog/2017/webassembly-a-new-hope/ - WebAssembly is really fast, the different is less than you'd expect.
  - jsheard 8y ago
    It's still getting faster too, e.g. engines are starting to use trap-based bounds checking which greatly reduces overhead when running on 64-bit platforms.
    - nneonneo 8y ago
      Could you elaborate on “trap-based bounds checking”, or provide a reference to learn more? My searching mostly pointed to “trap” as being a WASM concept, rather than some processor feature that improves bounds checks.
      - jules 8y ago
        It means using the processor's memory protection features to prevent programs from reading memory that they're not supposed to read, rather than inserting check instructions at every memory access.
        jsheard 8y ago
        Yeah, the V8 devs go into detail here: https://docs.google.com/document/d/17y4kxuHFrVxAiuCP_FFtFA2HP5sNPsCD10KEx17Hz6M/edit https://docs.google.com/document/d/17y4kxuHFrVxAiuCP_FFtFA2H... They just recently shipped it on Linux with V8 v6.8, but the Windows implementation is still a work in progress.
  - jules 8y ago
    Excellent post! Webassembly appears to be approximately half as fast as native. Do you know where that gap comes from, and how much of it can be expected to close?
vanderZwan 8y ago
Hey, thanks for the interesting article, and the benchmark of course! One bit of constructive feedback: add a date of publishing to the article. PSPDFKit already has multiple articles on WASM before, and it's nice to be able to tell which one is the most "up to date" at a glance.
mankash666 8y ago
Hello Martin - slightly off topic. There's no pricing section on your website. Does one have to get in touch with sales for a quote?
- MartinMond 8y ago
  Yes, please contact our sales team to discuss your use case. We sell to indie developers, early startups up to large Fortune 100 companies with a wide range of use cases so we found custom pricing to be the best way for us to be able to sell our software to everyone and at the same time support our team size.
Wurdan 8y ago
Hi there, Thanks for publishing this benchmark, but I've got a question about the results. The description of the charts states that 'A lower score is better', and between the two charts you say 'when we compare WebAssembly with our JavaScript fallback ... all browsers except Firefox are still slower'. But WebAssembly has a lower score than JavaScript on all browser/OS combinations except Chrome67/macOS, Safari/macOS and Edge/Win10. Could you clarify which way the results are pointing?

SXX 8y ago

Any chance you also benchmarked WA version against native code? What are results in your case?

steipete 8y ago
We did that in https://pspdfkit.com/blog/2017/webassembly-a-new-hope/ https://pspdfkit.com/blog/2017/webassembly-a-new-hope/ - WebAssembly is really fast, the different is less than you'd expect.
- jsheard 8y ago
  It's still getting faster too, e.g. engines are starting to use trap-based bounds checking which greatly reduces overhead when running on 64-bit platforms.
  - nneonneo 8y ago
    Could you elaborate on “trap-based bounds checking”, or provide a reference to learn more? My searching mostly pointed to “trap” as being a WASM concept, rather than some processor feature that improves bounds checks.
    - jules 8y ago
      It means using the processor's memory protection features to prevent programs from reading memory that they're not supposed to read, rather than inserting check instructions at every memory access.
      - jsheard 8y ago
        Yeah, the V8 devs go into detail here: https://docs.google.com/document/d/17y4kxuHFrVxAiuCP_FFtFA2HP5sNPsCD10KEx17Hz6M/edit https://docs.google.com/document/d/17y4kxuHFrVxAiuCP_FFtFA2H... They just recently shipped it on Linux with V8 v6.8, but the Windows implementation is still a work in progress.
- jules 8y ago
  Excellent post! Webassembly appears to be approximately half as fast as native. Do you know where that gap comes from, and how much of it can be expected to close?

vanderZwan 8y ago

Hey, thanks for the interesting article, and the benchmark of course! One bit of constructive feedback: add a date of publishing to the article. PSPDFKit already has multiple articles on WASM before, and it's nice to be able to tell which one is the most "up to date" at a glance.

mankash666 8y ago

Hello Martin - slightly off topic. There's no pricing section on your website. Does one have to get in touch with sales for a quote?

MartinMond 8y ago
Yes, please contact our sales team to discuss your use case. We sell to indie developers, early startups up to large Fortune 100 companies with a wide range of use cases so we found custom pricing to be the best way for us to be able to sell our software to everyone and at the same time support our team size.

Wurdan 8y ago

Hi there, Thanks for publishing this benchmark, but I've got a question about the results. The description of the charts states that 'A lower score is better', and between the two charts you say 'when we compare WebAssembly with our JavaScript fallback ... all browsers except Firefox are still slower'. But WebAssembly has a lower score than JavaScript on all browser/OS combinations except Chrome67/macOS, Safari/macOS and Edge/Win10. Could you clarify which way the results are pointing?