[QUESTION] Addressing performance issue to export a presentation due to `jszip` poor performance with `GenerateAsync`
Category
- [ ] Enhancement
- [ ] Bug
- [x] 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.
https://github.com/gitbrent/PptxGenJS/blob/96bee36e1e2f214329d1054fdcac15d787b2ba0a/src/pptxgen.ts#L529
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 https://github.com/Stuk/jszip/issues/617
This matches my observations.
None of the workaround discussed on jszip GitHub worked for me.
- https://github.com/Stuk/jszip/pull/702
- https://github.com/Stuk/jszip/pull/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.