Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Initial delay in web-app after page loads

See original GitHub issue

Hi, After watching Brad Traversy’s crash course on brython, I decided to code a web-app using it. It is a calculator app with some math functions. You can find it here. The problem is that after the web page loads, the app does not respond until nearly 50s or so. This happens only the first time - on reload, there is no delay. To recreate the issue, you would need to clear the browser’s cache and then reload the page. My repo is here . I am importing only the functools and math standard library Python modules. I am not using any cdn - all files are local. Please help me debug this problem. Thanks, Debashish

Issue Analytics

State:
Created 3 years ago
Comments:9 (4 by maintainers)

Top GitHub Comments

1reaction

PierreQuentelcommented, Apr 27, 2020

Sorry in advance for the long answer, but the problem is one of the 2 most difficult challenges Brython has to face (the other being generators, a nightmare !).

1. some modules require many, many other modules

Your code only has 3 imports : modules browser and math don’t import anything else, but it’s not the same for functools:

functools must import modules _thread, collections, reprlib, weakref, _functools at module level, and may import modules typing, abc, reprlib, types, warnings inside functions
warnings must import sys, traceback, linecache, re, tracemalloc
re must import sre_constants, copyreg, sre_parse, _locale, functools, enum, sre_compile

and so on, and so on. In the end, just because of functools you end up having to precompile about 64% of the standard library (brython_modules.js for your application is 2,3 MB compared to 3,6 for brython_stdlib.js).

The most frustrating is that in fact your application only uses 17 modules, because it doesn’t need any of the modules that functools may import ! But since it’s impossible to know in advance if they will be used, all modules have to be precompiled to JS and stored in the cache.

2. ideal solution, and why it’s not possible 😦

Ideally, translating to Javascript and storing in cache could happen at runtime : when Brython runs

import a
print(a.x)

the algorithm could be:

execute code “import a”
see if module a is in the cache
- if not, get the Python code of module a, translate to Javascript, store in indexedDB
- else, load from indexedDB
execute code “print(a.x)”

Unfortunately this is not possible because, by design, access to indexedDB is asynchronous (non-blocking) : storing into or reading from the database doesn’t stop the program execution, which means that the next instruction (“print(a.x)”) is executed just after the asynchronous call is done, not when this call completes. Of course, since “import a” is not completed, “print(a.x)” fails.

The only possible thing (at least the only one I found…) is to precompile and store in cache before starting to run the program. And with hundreds of modules to compile and store, it takes dozens of seconds…

3. workarounds

There are at least 2 workarounds (I ignore the radical solution of not using functools at all 😉

don’t use the indexedDB database, by setting the option indexedDB to false :

<body onload="brython({indexedDB: false})">

In this case, the cache is not used and all modules are compiled to Javascript at each run. All runs take about the same time, which is much less than the first import with indexedDB but more than with the next runs with the cache

if you keep the indexedDB cache:
- hide the calculator on page load (style.display = "none") and show a DIV with something like “Loading, please wait, it will be faster next time…” (maybe with a timeout of 1 or 2 seconds so that it will show only in the first run)
- after the imports, remove this DIV and display the calculator

I am conscious that this is not ideal, if someone can think of a better solution I would be extremely pleased !

0reactions

deb17commented, Apr 28, 2020

@PierreQuentel Thanks a lot for taking the trouble of clearing my doubts! I am going to close the issue.