emscripten-core/emscripten

DOC Optimizing WASM browser compilation time

Open

#15 249 ouverte le 6 oct. 2021

Voir sur GitHub
 (0 commentaires) (0 réactions) (0 assignés)C++ (3 519 forks)batch import
docsgood first bughelp wanted

Métriques du dépôt

Stars
 (27 361 stars)
Métriques de merge PR
 (Merge moyen 19j 10h) (147 PRs mergées en 30 j)

Description

The documentation on optimizing compilation and optimizing load time are quite nice.

I wonder if anyone could share optimization advice specifically for the WASM compilation time in the browser. Are there options that are known to affect it, well besides the size of the produced .wasm objects? We found out that it's the bottleneck in Pyodide for large scientific Python packages (https://github.com/pyodide/pyodide/issues/347#issuecomment-933834657)

Also the documentation on the manual persistance of compiled modules to IndexedDB might need to be updated, https://github.com/emscripten-core/emscripten/blame/2595d3f703b6d6eaf312a2b027ef66c6ab3c1031/site/source/docs/compiling/Deploying-Pages.rst#L44 since that was deprecated https://github.com/WebAssembly/spec/issues/821

Guide contributeur

Direction de recherche
Cette demande sollicite une documentation sur l'optimisation du temps de compilation WASM dans le navigateur. Le demandeur pointe vers la documentation existante sur l'optimisation de la compilation et du temps de chargement, et mentionne un problème spécifique dans Pyodide. Un contributeur doit d'abord examiner les fichiers de documentation liés : site/source/docs/optimizing/Optimizing Code.html et site/source/docs/compiling/Deploying Pages.rst. De plus, la demande mentionne une dépréciation de la persistance manuelle vers IndexedDB, donc il faut enquêter sur son statut dans la spécification WebAssembly. Recueillez des informations à partir du problème Pyodide et de la communauté Emscripten pour compiler une nouvelle section ou mettre à jour les pages existantes.
Stack technique
cppwasm
Domaine
documentation
Type d'issue
Documentation
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
Git
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
70