rerender 80x slower with v1 than v0

[minrk]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

rerendering recipes with a large number of variants (e.g. petsc with 44 variants, petsc4py with 223) is quite a lot slower after switching to v1.

For example, rerendering petsc (mac, m1 pro) with meta.yaml takes 20 seconds with meta.yaml and 4 minutes with v1 recipe.yaml. For petsc4py's 223 variants, it takes 27 minutes to rerender the v1 recipe compared with still only 20 seconds for v0, or rattler-build is more than 80 times slower than conda-build when rerendering.

Here's a CI rerender of petscp4y, taking 38 minutes: https://github.com/conda-forge/conda-forge-webservices/actions/runs/13052932975/job/36417048480

Basically all of this time is in rattler_build_conda_compat.render.render (as measured by pyinstrument $(which conda-smithy) rerender -c auto --no-check-uptodate):

Installed packages

conda                     24.9.2          py311h267d04e_0    conda-forge
conda-build               24.9.0          py311h267d04e_0    conda-forge
conda-forge-feedstock-ops 0.8.1.dev1+gca4306c          pypi_0    pypi
conda-forge-pinning       2024.11.21.05.29.27      hd8ed1ab_0    conda-forge
conda-index               0.5.0              pyhd8ed1ab_0    conda-forge
conda-libmamba-solver     24.9.0             pyhd8ed1ab_0    conda-forge
conda-lock                2.5.7              pyhd8ed1ab_0    conda-forge
conda-pack                0.8.1              pyhd8ed1ab_1    conda-forge
conda-package-handling    2.4.0              pyh7900ff3_0    conda-forge
conda-package-streaming   0.11.0             pyhd8ed1ab_0    conda-forge
conda-recipe-manager      0.4.0              pyhd8ed1ab_0    conda-forge
conda-smithy              3.45.4          unix_pyhd81877a_0    conda-forge
conda-souschef            2.2.3              pyhd8ed1ab_0    conda-forge
conda-standalone          24.11.0              hce30654_0    conda-forge
conda-store               2024.11.2          pyh534df25_0    conda-forge
conda-store-server        2024.11.2          pyh534df25_0    conda-forge
conda-verify              3.4.2              pyhd8ed1ab_0    conda-forge
rattler-build             0.35.9               h3ab7716_0    conda-forge
rattler-build-conda-compat 1.3.3              pyhd8ed1ab_0    conda-forge

Environment info

mamba version : 1.5.10
     active environment : None
            shell level : 0
       user config file : /Users/minrk/.condarc
 populated config files : /Users/minrk/conda/.condarc
                          /Users/minrk/.condarc
          conda version : 24.9.2
    conda-build version : 24.9.0
         python version : 3.11.10.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=m1
                          __conda=24.9.2=0
                          __osx=15.3=0
                          __unix=0=0
       base environment : /Users/minrk/conda  (writable)
      conda av data dir : /Users/minrk/conda/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/osx-arm64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : /Users/minrk/conda/pkgs
                          /Users/minrk/.conda/pkgs
       envs directories : /Users/minrk/conda/envs
                          /Users/minrk/.conda/envs
               platform : osx-arm64
             user-agent : conda/24.9.2 requests/2.32.3 CPython/3.11.10 Darwin/24.3.0 OSX/15.3 solver/libmamba conda-libmamba-solver/24.9.0 libmambapy/1.5.10
                UID:GID : 501:20
             netrc file : /Users/minrk/.netrc
           offline mode : False

[wolfv]

This is interesting. Currently, the way rendering works is that it calls out to rattler-build to render the recipe with a given set of variables. There are definitely many ways in which things could be optimized. It's very good to have a problematic case that we can use to benchmark against :)

[minrk]

I should link to the significant optimizations that happened in conda-build rerenders last year, which used to have similar performance, probably for similar reasons:

• reduce input variants to only _used_ input variants #1968
• petsc rerender error regro/cf-scripts#2561
• reduce cost of large variant matrix conda/conda-build#5392

The issue wasn't actually the 223 final variants of petsc4py, but rather the ~13,000 unused variants coming from conda-forge-pinning that still get computed before being discarded. Thinning the 'used variables' as soon as possible helped a ton. I imagine the rattler-build case may be similar.

Computing 'used variables' may be a lot less fraught in v1 recipes than it is in v0, thanks to the new selectors, so maybe we can compute it earlier with more confidence. That's what held up conda/conda-build#5392 - it was too hard to compute used_variables rigorously without full renders.

[wolfv]

I need to look into the code here again. In rattler-build we also added support for parsing conda_build_config.yaml files, so we could now even point to the original large pinning file and it should still be pretty quick.