You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typical asset load times reported by the web app are:
Looking for 20241204 assets in [ https://data.desi.lbl.gov/desi/engineering/focalplane/endofnight/20241204 ]
20241204 has 45 positioning exposures
Loaded moves in 10623ms
Loaded summary in 1311ms
Loaded front image in 2595ms
Loaded back image in 3264ms
The corresponding file sizes are (the calib and hwtables files are not being read yet):
I suspect that the >10s needed to load the moves is mostly due to gzip decompression, rather than the network transfer, but this needs to be confirmed. The relatively new DecompressionStream API looks promising to speed this up.
Another thing to check is whether these files are being loaded in parallel (as intended) or serially.
The text was updated successfully, but these errors were encountered:
Looking at this 2020 SO post from the author of the fflate pkg (which we use now), the native DecompressionStream may not be any faster, or perhaps things have changed in 4 years?
Typical asset load times reported by the web app are:
The corresponding file sizes are (the calib and hwtables files are not being read yet):
I suspect that the >10s needed to load the moves is mostly due to gzip decompression, rather than the network transfer, but this needs to be confirmed. The relatively new DecompressionStream API looks promising to speed this up.
Another thing to check is whether these files are being loaded in parallel (as intended) or serially.
The text was updated successfully, but these errors were encountered: