[QUESTION] Addressing performance issue to export a presentation due to jszip poor performance with GenerateAsync

[fpaupier]

Category

• Enhancement
• Bug
• Question
• Documentation gap/issue

Version

• What version of the library you are using: [latest]
• What version(s) of PowerPoint you are targeting: [latest]

Context

I use this library to generate & download a pptx from the browser, I tried in a minimal create react app and it all works fine, amazing lib, very clear and concise API, kudos to the maintainer. 👍

However, when trying to export my presentation from a chromium-browser (version 83.0.4103.122.) used in a QML WebEngine, I experienced a severe performance issue for the pptx export.

• It takes around 72s to export a presentation with a single slide with a 30kb png image while it takes less than a second in the create react app environment on firefox.
  • I've carefully read and applied the considerations on using base 64 encoded images, so I doubt it's due to that.

Research so far

I noticed this library uses the jszip lib to generate the ppptx. With some profiling, I realized that it's the function call zip.generateAsync in src/pptxgen.ts that's the root cause of this slowdown. Most of the time, the CPU is idle.

PptxGenJS/src/pptxgen.ts

Line 529 in 96bee36

return zip.generateAsync({ type: 'blob', compression: props.compression ? 'DEFLATE' : 'STORE' })

On the jszip repo, I noticed performance has been a critical issue since version 3.1.5 onwards. In PptxGenJS, we rely on "jszip": "^3.7.1", this version is affected by the slowdown.

Since the v3.1.5, GenerateAsync is ~50x slower as described in Stuk/jszip#617
This matches my observations.

None of the workaround discussed on jszip GitHub worked for me.

• Improve better performance Stuk/jszip#702
• Fix performance issue with setImmediate Stuk/jszip#619

Question

Did anyone else encounter a similar issue? If so, what workarounds worked for you?

Side note

Posting here since at the time of this writing, the jszip core maintainer does not seem active.
I know this issue isn't related to this repo, but to a third-party dependency. Still, I'd be curious to know if some of you encountered a similar performance issue and what you've done to address it.