You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While troubleshooting a workflow that included a lot of salt.match.compound() calls in Jinja, it was noticed that the function call contributed quite a bit of time to the overall workflow duration. Upon further investigation, it was found that every function call in the match module is invoking the Salt Loader on every run. To make matters worse, the compound matcher is invoking the Salt Loader again to pull in each distinct match type... so a call to compound matching invokes the Salt Loader twice on every call.
Setup
This simple script was used to test the compound match function calls at scale.
As far as I can tell, there's no reason to invoke the Salt Loader for known-present matchers since we're not relying on __virtual__() to selectively load matchers or storing the loaded matchers in a location (like __salt__) where they can be invoked without incurring loader overhead each time.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
Salt: 3004.2Dependency Versions:
cffi: Not Installedcherrypy: Not Installeddateutil: 2.7.3docker-py: Not Installedgitdb: 2.0.5gitpython: 2.1.11Jinja2: 2.10libgit2: Not InstalledM2Crypto: Not InstalledMako: Not Installedmsgpack: 0.5.6msgpack-pure: Not Installedmysql-python: Not Installedpycparser: Not Installedpycrypto: 2.6.1pycryptodome: 3.6.1pygit2: Not InstalledPython: 3.7.3 (default, Jan 22 2021, 20:04:44)python-gnupg: Not InstalledPyYAML: 3.13PyZMQ: 17.1.2smmap: 2.0.5timelib: Not InstalledTornado: 4.5.3ZMQ: 4.3.1Salt Extensions:
saltext.prometheus: 1.1.1System Versions:
dist: debian 10 busterlocale: UTF-8machine: x86_64release: 4.19.0-20-amd64system: Linuxversion: Debian GNU/Linux 10 buster
Additional context
The slowdown here isn't significant enough to notice with "normal" targeting. The match functions would need to be called many times in quick succession, so this really affects function calls in Jinja and custom code.
The text was updated successfully, but these errors were encountered:
This PR changes match functions from loader access to direct imports of
the matchers in order to yield much faster results.
(cherry picked from commit ce20510)
Backported-from: saltstack#62295Fixes: saltstack#62283
Signed-off-by: Joe Groocock <jgroocock@cloudflare.com>
Description
While troubleshooting a workflow that included a lot of
salt.match.compound()
calls in Jinja, it was noticed that the function call contributed quite a bit of time to the overall workflow duration. Upon further investigation, it was found that every function call in thematch
module is invoking the Salt Loader on every run. To make matters worse, the compound matcher is invoking the Salt Loader again to pull in each distinct match type... so a call to compound matching invokes the Salt Loader twice on every call.Setup
This simple script was used to test the compound match function calls at scale.
Steps to Reproduce the behavior
Running the script above results in fairly slow operation at scale.
Expected behavior
Changing to direct imports of the matchers yields much faster results.
Direct import diff for reference.
As far as I can tell, there's no reason to invoke the Salt Loader for known-present matchers since we're not relying on
__virtual__()
to selectively load matchers or storing the loaded matchers in a location (like__salt__
) where they can be invoked without incurring loader overhead each time.Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Additional context
The slowdown here isn't significant enough to notice with "normal" targeting. The match functions would need to be called many times in quick succession, so this really affects function calls in Jinja and custom code.
The text was updated successfully, but these errors were encountered: