Skip to content

Reduce overhead of spack install pkg for develop environments.#51518

Closed
vbrunini wants to merge 2 commits intospack:developfrom
vbrunini:vebruni/noop_install_performance
Closed

Reduce overhead of spack install pkg for develop environments.#51518
vbrunini wants to merge 2 commits intospack:developfrom
vbrunini:vebruni/noop_install_performance

Conversation

@vbrunini
Copy link
Copy Markdown
Contributor

@vbrunini vbrunini commented Nov 6, 2025

We are moving to using spack to drive day to day development of a group of related packages. In the process we have noticed that there is a someoverhead running some commands like spack install for an incremental build where only a small number of files in one or two packages were modified when compared to directly running the packages build system.

Combined with #51367 and the reduced install task sleep time from #51491 this reduces the time for a no-op install of a development environment with 94 packages (including dependencies) from 8s to 2.8s for me. It also provides a similar reduction in time for spack build-env --dump env.txt mypkg which we frequently use to start a shell with the build environment.

@psakievich

By using a cache for Spec objects and reducing the number of copies
of Spec objects being done. Combined with spack#51367 and the reduced install
task sleep time from spack#51491 this reduces the time for a no-op install of
a development environment with 94 packages (including dependencies) from 8s
to 2.8s for me. It also provides a similar reduction in time for
`spack build-env --dump env.txt mypkg` which we frequently use to start a
shell with the build environment.

Signed-off-by: Victor Brunini <[email protected]>
@haampie haampie added this to the v1.2.0 milestone Nov 6, 2025
@haampie
Copy link
Copy Markdown
Member

haampie commented Nov 6, 2025

This seems to have a larger scope than "develop environments". Maybe split into parts? Some changes look controversial from skimming the diff.

@vbrunini
Copy link
Copy Markdown
Contributor Author

vbrunini commented Nov 6, 2025

This seems to have a larger scope than "develop environments". Maybe split into parts? Some changes look controversial from skimming the diff.

In my mind it's mostly relevant for the iterative development use case because these relatively small overheads of a few seconds aren't as impactful when doing full package builds compared to incremental builds with a small number of modified files, but yes the code changes certainly impact other cases as well.

Any suggestions on how to split it up? I can split the two commits into separate PRs, but most of the changes are just from the first commit. If you'd like that one split up I think the two logical pieces are:

  1. Caching the __hash__ result for non-concrete specs
  2. The Spec.get_spec() cache usage.
    Would that split help?

@vbrunini
Copy link
Copy Markdown
Contributor Author

vbrunini commented Nov 8, 2025

Split up into #51535 , #51536 , and #51537 .

@vbrunini vbrunini closed this Nov 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants