Wasm Threads vs Standard Wasm tradeoffs

I have been running tests on different workflows and workloads to determine whether using wasm threads is worth the hassle. It would be fairly difficult to make my site Cross-origin Isolated. I am currently using an Origin Trial for testing purposes.

While doing this, I am hoping someone can elaborate on some of the testing done at PDFTron and what types of workloads you might expect to see benefit.

I will elaborate on some of our workflows and if you could answer and possibly elaborate further I would be grateful.

Workflow 1:

User loads PDF using ‘lean’ PDF core. Median file is ~1 page and 0.5 - 1.5 MB. Architectural/engineering PDF heavy on CAD symbology. User loads the PDF, creates some annotations, zooms around the large page and exits.

Workflow 2:

User loads PDF using ‘lean’ PDF core. PDF is 40 pages and 55 MB. All complex CAD drawings. There are around ~150 annotations loaded via XFDF. User navigates the thumbnail view, zooms around pages, creates and modifies annotations, and uses the search function to find things in the PDF.

Workflow 3:

User loads a comparison of 2 PDF files using the ‘full’ PDF core. Files are of varying sizes and complexities. Standard ‘appendVisualDiff’ is used.

Workflow 4:

User loads PDF with ‘lean’ core files. While in the same UI (no reload) user loads 5-10 other PDFs of various sizes (each PDF being removed as a new one loads).

Workflow 5:

User loads PDF using ‘full’ core files. User navigates fillable form fields using calls to your API and we highlight and scroll directly to the fields based on different inputs in the UI. (Think DocuSign or something where you navigate to every signature field quickly).

Workflow 6:

Do similar worklows as above, except with .xlsx, .docx, etc…

Basically, when and where does wasm threads make a significant difference and how much of a difference does it make. In some workflows I would prioritize loading speed (standard loading and interaction) and other times I would prioritize overall speed for lower end devices or on very complex drawings.

This would also make good material for the wiki/guides area.

Hello, I’m Ron, an automated tech support bot :robot:

While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:

Guides:APIs:Forums:

Hello,
Thank you for getting in touch with us about this.
With the threaded backend:

  1. Rendering complicated files will be somewhat faster. Most likely this will make some difference in your use case.
  2. Doing multiple read operations simultaneously will be much faster. (i.e. Rendering two pages, extracting annotations or text while rendering another page.) This is because the threaded backend can do two at once while the non-threaded backend can only do one.
  3. I would also expect downloading large files incrementally to benefit from threading.

Most other things including loading speed, PDF editing operations and the performance of PDFNetJS full operations (like appendDiff) would be pretty similar.

You could try it out and make a decision based on that. If the performance of the non-threaded backend is good enough you could just stick with that. We do recognize that the cross-origin restrictions needed to enable threads can be a bit limiting and hard to work around.