Cool, thanks. Note that there are at least two sources of long startup time for Datashader, i.e. imports and Numba compilation. I think only once Numba can be precompiled and/or cached (which is supposed to be possible already) will the startup time be reasonable.

Codecov Report

Attention: Patch coverage is 75.88235% with 41 lines in your changes missing coverage. Please review.

Project coverage is 87.95%. Comparing base (82a57c1) to head (c74fb8f).

@@            Coverage Diff             @@
##             main    #1419      +/-   ##
==========================================
- Coverage   88.46%   87.95%   -0.51%     
==========================================
  Files          94       95       +1     
  Lines       18683    18662      -21     
==========================================
- Hits        16527    16415     -112     
- Misses       2156     2247      +91     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Cool, thanks. Note that there are at least two sources of long startup time for Datashader, i.e. imports and Numba compilation. I think only once Numba can be precompiled and/or cached (which is supposed to be possible already) will the startup time be reasonable.

Yes, it could be great also to tackle that, but just by looking at the profiler, I can see, e.g., dask.dataframe accounted for half of the import time, and pandas a little below 2/10.

If I lazy load pandas (and therefore xarray and comment out some ragged extension inheritance for now), I can get it down to the following:

❯ hyperfine "python -c ''" "python -c 'import datashader'" --warmup 5
Benchmark 1: python -c ''
  Time (mean ± σ):       9.6 ms ±   0.7 ms    [User: 6.6 ms, System: 2.9 ms]
  Range (min … max):     7.7 ms …  11.8 ms    277 runs

Benchmark 2: python -c 'import datashader'
  Time (mean ± σ):     298.7 ms ±  14.9 ms    [User: 1847.7 ms, System: 57.0 ms]
  Range (min … max):   284.5 ms … 331.5 ms    10 runs

Summary
  python -c '' ran
   31.19 ± 2.67 times faster than python -c 'import datashader'

That's great! What I was bringing up was the time to the first datashaded result, not the time for an import that isn't used. Are we often importing datashader without actually using it?

What I was bringing up was the time to the first datashaded result, not the time for an import that isn't used.

I understand that this is the main problem, but it is outside the scope of this PR. But something we should improve at some point.

Are we often importing datashader without actually using it?

I don't think so, but when we do import it, we import a lot of stuff we don't necessarily need. For example, if we want to rasterize a pandas DataFrame, we try to import dask.DataFrame. This, at least for me, causes unnecessary slowdown, because I have Dask installed in my development environment.