-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add lazy matchers #173
Milestone
Comments
masklinn
added a commit
to masklinn/uap-python
that referenced
this issue
Feb 13, 2024
Support is addef for lazy builtin matchers (with a separately compiled file), as well as loading json or yaml files using lazy matchers. Lazy matchers are very much a tradeoff: they improve import speed, but slow down run speed, possibly dramatically. Use them by default for the re2 parser, but not the basic parser: experimentally, on Python 3.11 - importing the package itself takes ~36ms - importing the lazy matchers takes ~36ms (including the package, so ~0) - importing the eager matchers takes ~97ms the eager matchers have a significant overhead, *however* running the bench on the sample file, they cause a runtime increase of 700~800ms on the basic parser bench, as that ends up instantiating *every* regex (likely due to match failures). Relatively this is not huge (~2.5%), but the tradeoff doesn't seem great, especially since the parser itself is initialized lazily. The re2 parser does much better, only losing 20~30ms (~1%), this is likely because it only needs to compile a fraction of the regexes (156 out of 1162 as of regexes.yaml version 0.18), and possibly because it gets to avoid some of the most expensive to compile ones. Fixes ua-parser#171, fixes ua-parser#173
masklinn
added a commit
to masklinn/uap-python
that referenced
this issue
Feb 17, 2024
Support is added for lazy builtin matchers (with a separately compiled file), as well as loading json or yaml files using lazy matchers. Lazy matchers are very much a tradeoff: they improve import speed, but slow down run speed, possibly dramatically. Use them by default for the re2 parser, but not the basic parser: experimentally, on Python 3.11 - importing the package itself takes ~36ms - importing the lazy matchers takes ~36ms (including the package, so ~0) - importing the eager matchers takes ~97ms the eager matchers have a significant overhead, *however* running the bench on the sample file, they cause a runtime increase of 700~800ms on the basic parser bench, as that ends up instantiating *every* regex (likely due to match failures). Relatively this is not huge (~2.5%), but the tradeoff doesn't seem great, especially since the parser itself is initialized lazily. The re2 parser does much better, only losing 20~30ms (~1%), this is likely because it only needs to compile a fraction of the regexes (156 out of 1162 as of regexes.yaml version 0.18), and possibly because it gets to avoid some of the most expensive to compile ones. Fixes ua-parser#171, fixes ua-parser#173
masklinn
added a commit
to masklinn/uap-python
that referenced
this issue
Feb 17, 2024
Support is added for lazy builtin matchers (with a separately compiled file), as well as loading json or yaml files using lazy matchers. Lazy matchers are very much a tradeoff: they improve import speed, but slow down run speed, possibly dramatically. Use them by default for the re2 parser, but not the basic parser: experimentally, on Python 3.11 - importing the package itself takes ~36ms - importing the lazy matchers takes ~36ms (including the package, so ~0) - importing the eager matchers takes ~97ms the eager matchers have a significant overhead, *however* running the bench on the sample file, they cause a runtime increase of 700~800ms on the basic parser bench, as that ends up instantiating *every* regex (likely due to match failures). Relatively this is not huge (~2.5%), but the tradeoff doesn't seem great, especially since the parser itself is initialized lazily. The re2 parser does much better, only losing 20~30ms (~1%), this is likely because it only needs to compile a fraction of the regexes (156 out of 1162 as of regexes.yaml version 0.18), and possibly because it gets to avoid some of the most expensive to compile ones. Fixes ua-parser#171, fixes ua-parser#173
masklinn
added a commit
to masklinn/uap-python
that referenced
this issue
Feb 18, 2024
Add lazy builtin matchers (with a separately compiled file), as well as loading json or yaml files using lazy matchers. Lazy matchers are very much a tradeoff: they improve import speed (and memory consumption until triggered), but slow down run speed, possibly dramatically: - importing the package itself takes ~36ms - importing the lazy matchers takes ~36ms (including the package, so ~0) and ~70kB RSS - importing the eager matchers takes ~97ms and ~780kB RSS - triggering the instantiation of the lazy matchers adds ~800kB RSS - running bench on the sample file using the lazy matcher has 700~800ms overhead compared to the eager matchers While the lazy matchers are less costly across the board until they're used, benching the sample file causes the loading of *every* regex -- likely due to matching failures -- has a 700~800ms overhead over eager matchers, and increases the RSS by ~800kB (on top of the original 70). Thus lazy matchers are not a great default for the basic parser. Though they might be a good opt-in if the user only ever uses one of the domains (especially if it's not the devices one as that's by far the largest). With the re2 parser however, only 156 of the 1162 regexes get evaluated, leading to a minor CPU overhead of 20~30ms (1% of bench time) and a more reasonable memory overhead. Thus use the lazy matcher fot the re2 parser. On the more net-negative but relatively minor side of things, the pregenerated lazy matchers file adds 120k to the on-disk requirements of the library, and ~25k to the wheel archive. This is also what the _regexes and _matchers precompiled files do. pyc files seem to be even bigger (~130k) so the tradeoff is dubious even if they are slightly faster. Fixes ua-parser#171, fixes ua-parser#173
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #171
This should be reasonably easy with the API changes of #116.
Matchers
should probably be a triple of lists ofMatcher[*]
, whereMatcher
isand we can update e.g.
class UserAgentMatcher(Matcher[UserAgent])
, making the typing line up (hopefully).The question is how to provide the lazy versions of the matchers:
callback
somehow? Not sure there's any way that can work, might make more sense with a wrapper converting that to a list and the callbacks are just intermediate convenience?The text was updated successfully, but these errors were encountered: