[Starlingx-discuss] Flock Versioning for packaging

[Jeremy Stanley]

On 2019-05-15 20:18:49 +0000 (+0000), Bailey, Henry Albert (Al) wrote:
[...]
> The other (minor) thing to be aware of is the cost of querying the
> pbr version. Pbr makes use of pkg_resources, which processes all
> python files in order to determine entry_points, etc..
> 
> You incur this cost during import (only once per process).
> Typically about half a second in python2.  I don't know about
> python3. I remember explicitly turning it off for cgtsclient, but
> the savings are begated  if there are any other python imports
> (like keyring) that are also using pkg_resources.
[...]

As of PBR 2.1.0 the penalty can be deferred by separating your
version query function out to a separate module and lazy-loading
that only when the version info is actually needed, so depending on
the software this could be an option (though if you want to log the
version to a file at startup, not so much). The delay is also
relative not only to system performance but also to the number of
Python packages installed into the same context, so if this is
happening in a venv or maybe a container with only a minimal number
of Python packages installed then it can be almost instantaneous
(but does get really slow if you have hundreds of Python
dependencies installed).

For long-running processes it's usually not much of a concern
anyway, but for some Python script you're forking repeatedly in
rapid succession in a loop the overhead can quickly become
crippling. We've toyed with the idea of caching pkg-resources
lookups on disk, but then you get into the fun spot of deciding how
to tell when you need to invalidate and refresh it.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190515/917987af/attachment.sig>