Skip to content

Memoise version object construction when sorting catalog parts - #540

Open
citrus-it wants to merge 1 commit into
omniosorg:masterfrom
citrus-it:memo_version
Open

Memoise version object construction when sorting catalog parts#540
citrus-it wants to merge 1 commit into
omniosorg:masterfrom
citrus-it:memo_version

Conversation

@citrus-it

Copy link
Copy Markdown
Member

No description provided.

CatalogPart.sort() constructs a pkg.version.Version object for every entry
each time a part is sorted. Version construction is expensive, and sorting
happens on every catalog finalise - i.e. package publication, pkgrepo
refresh/rebuild, and the client's image catalog rebuild.

The same version string commonly recurs across many stems, because packages
built and published together share a branch and, where the publisher stamps
a build's packages with a shared timestamp, the whole version string.
Construct each distinct version string only once per sort, via a memo
dictionary local to the sort call.

The win scales with the amount of duplication in the catalog. For a
repository whose builds are published with a single shared timestamp, a
full three-part sort drops from 2.00s to 0.35s. The OmniOS core repository
currently has only minimal duplication (1.86x, from packages that happen to
publish within the same second) and benefits proportionately less) In the
pkg5 test suite, TestPkgRepo runs 39s faster, TestPkgSign 27s faster and
TestLintEngineDepot 29% faster with this change.

The publication path already honours a timestamp provided on the FMRI, so a
repository can opt into the full benefit simply by publishing each build's
packages with a shared timestamp (we should do this for core illumos-omnios
packages which already have a shared 0.5.11 version stem).
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