metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cestella <>
Subject [GitHub] incubator-metron pull request #473: METRON-712: Separate evaluation from par...
Date Mon, 06 Mar 2017 14:29:06 GMT
GitHub user cestella opened a pull request:

    METRON-712: Separate evaluation from parsing in Stellar

    # Description
    With the current implementation of Stellar, we cannot cache the parse tree and then apply
it after the fact. It's just an artifact of how we do the parsing: we actually execute the
statement as we parse rather than constructing an AST that can then be evaluated later given
a message. Essentially what I'm proposing is that we build the equivalent of Pattern.compile()
in Java except for Stellar.
    We should for multiple reasons:
    * code clarity - decoupling the stellar language from the generated parser code
    * performance - saving lexing and parsing for every message.  Also, the resulting parse-stack
may be much smaller than the somewhat complex.
    In this PR, I have added a google cache that will cache the resulting compiled expression
in `BaseStellarProcessor` for 10 minutes (by default).  I have also created a microbenchmarking
suite and have evaluated this on a few representative expressions.
    * `TO_UPPER('casey')`
      * Median ms before: `880.5`
      * Median ms after: `15`
      * Speedup: 58.6x faster
    * `TO_LOWER(name)`
      * Median ms before: `497`
      * Median ms after: `3`
      * Speedup: 165.6x faster
    * `1 + 2*(3 + int_num) / 10.0`
      * Median ms before: `676`
      * Median ms after: `4`
      * Speedup: 169x faster
    * `1.5 + 2*(3 + double_num) / 10.0`
      * Median ms before: `634`
      * Median ms after: `1`
      * Speedup: 634x faster
    * `if ('foo' in ['foo']) OR one == very_nearly_one then 'one' else 'two'`
      * Median ms before: `616`
      * Median ms after: `23`
      * Speedup: 26x faster
    * `1 + 2*(3 + int_num) / 10.0`
      * Median ms before: `601`
      * Median ms after: `2`
      * Speedup: 300.5x faster
    * `DOMAIN_TO_TLD(domain)`
      * Median ms before: `505`
      * Median ms after: `16`
      * Speedup: 32.5x
      * Median ms before: `496`
      * Median ms after: `11`
      * Speedup: 45x faster
    # Testing Plan
    Please refer to the METRON-744 [PR](
testing plan.
    In order to streamline the review of the contribution we ask you follow these guidelines
and ask you to double check
    the following:
    ### For all changes:
    - [x] Is there a JIRA ticket associated with this PR? If not one needs to be created at
[Metron Jira](

    - [x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are
trying to resolve? Pay particular attention to the hyphen "-" character.
    - [x] Has your PR been rebased against the latest commit within the target branch (typically
    ### For code changes:
    - [x] Have you included steps to reproduce the behavior or problem that is being changed
or addressed?
    - [x] Have you included steps or a guide to how the change may be verified and tested
    - [x] Have you ensured that the full suite of tests and checks have been executed in the
root incubating-metron folder via:
    mvn -q clean integration-test install && build_utils/ 
    - [x] Have you written or updated unit tests and or integration tests to verify your changes?
    - [x] If adding new dependencies to the code, are these dependencies licensed in a way
that is compatible for inclusion under [ASF 2.0](

    - [ ] Have you verified the basic functionality of the build by building and running locally
with Vagrant full-dev environment or the equivalent?
    ### For documentation related changes:
    - [x] Have you ensured that format looks appropriate for the output in which it is rendered
by building and verifying the site-book? If not then run the following commands and the verify
changes via site-book/target/site/index.html.
    cd site-book
    mvn site:site
    ### Note:
    Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible.
    It is also recommened that [travis-ci]( is set up for your personal
repository such that your branches are built there before submitting a pull request.

You can merge this pull request into a Git repository by running:

    $ git pull stellar_optimize

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #473
commit 7c04584950c452b5f0dc786de8d91f3978bb92ec
Author: cstella <>
Date:   2017-03-06T08:15:57Z

    Renaming Compiler to Interpreter.

commit 7483361f395707a86031bc5eb7027259cc75786e
Author: cstella <>
Date:   2017-03-06T08:16:25Z

    Merge branch 'master' into stellar_optimize

commit c2e7eb08a9c001bc0eef62e5a0423cd17227ef46
Author: cstella <>
Date:   2017-03-06T10:21:54Z

    Added cache to speed up stellar

commit 3c416e7de9de7c96f80116884f264cab92f7f9e6
Author: cstella <>
Date:   2017-03-06T10:24:36Z

    Deleted StellarInterpreter.

commit fbad7f31e6171abf4a8e2e0031d207a2de41f5ac
Author: cstella <>
Date:   2017-03-06T11:22:36Z

    Adding microbenchmarking suite.

commit 7b9ce9a9a3b97059a25af05901f9077392a0e58a
Author: cstella <>
Date:   2017-03-06T13:36:02Z

    Updating tests to expect real exceptions, not wrapped exceptions.


If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message