-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collapsing identical reprs broken by caching #5
Comments
I ran some tests and generating the HTML is a significant chunk of the total time for large collections and can actually take longer than Another alternative I'm looking into is bypassing UUIDs altogether. Currently, UUIDs are used to tie the header The challenge is that making the |
Caching of reprs broke collapsing behavior that depended on unique UUIDs to tie label elements to hidden checkbox inputs. To fix that, labels and inputs are now connected implicitly by nesting elements. This change to the HTML structure prevents a pure CSS solution to collapsing, so a JS snippet was added to restore collapsing behavior. Skipping UUID generation substantially reduced HTML generation time and slightly decreased output HTML size. Another performance boost was achieved by removing singledispatch which has a substantial overhead and replacing with simple isinstance checks.
This is fixed by scrapping UUIDs and connecting |
Collapsing behavior is based on pseudo-random UUIDs generated for each
<ul>
in an objects repr. Because the repr is cached, printing the same object twice will return exactly the same repr with the same UUIDs. When you try to collapse the second repr, the first repr will (probably) get collapsed instead.For some reason, collapsing works correctly in Jupyter classic, Colab, and VS Code, but is broken in Jupyter Lab (including Binder) or when a notebook is rendered statically (nbviewer). I'm guessing this is an implementation detail since the UUID issue isn't platform-dependent.
The quick solution is to cache the Earth Engine data by wrapping
getInfo
instead of caching the repr, but regenerating the repr may be a non-negligible performance hit for huge collections. If performance is too slow I'll need to think about another solution, e.g. caching the repr but re-generating each pair of UUIDs.The text was updated successfully, but these errors were encountered: