RegEx Validation Using Java Patterns (perf) #176

olnrao · 2016-02-15T11:44:44Z

While using this library we found RhinoHelper takes way too much time for pattern validations using Visual VM CPU Profiling.

Here is an observation:

JSON Schema: Roughly 30 fields, 10 fields have one or the other validation, 5 of them have patterns (listed below)
Input Data: An array of 10K messages
Time Taken:
-- With out pattern annotation: ~6 seconds
-- With Rhino Helper: ~30 seconds
-- With Java Patterns: ~7 seconds

Patterns used:
"pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-",
"pattern" : "^[+-][0-1][0-9]:[0-5][0-9]$",
"pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-",
"pattern": "[^\s]{1}",
"pattern": "[^\s]{1}",

While using this library we found RhinoHelper takes way too much time for pattern validations using Visual VM CPU Profiling. Here is an observation: - JSON Schema: Roughly 30 fields, 10 fields have one or the other validation, 5 of them have patterns (listed below) - Input Data: An array of 10K messages - Time Taken: -- With out pattern annotation: ~6 seconds -- With Rhino Helper: ~30 seconds -- With Java Patterns: ~7 seconds Patterns used: "pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-", "pattern" : "^[+-][0-1][0-9]:[0-5][0-9]$", "pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-", "pattern": "[^\\s]{1}", "pattern": "[^\\s]{1}",

huggsboson · 2016-02-16T21:37:16Z

Hi, thanks for the pull request. Sadly the json-schema spec explicitly dictates that the patterns should be ecma-262 style regexes. Changing to just use java's pattern matcher will more than likely introduce some incompatibilities. Maybe if we can dependency inject the pattern matcher you can have your own "non-standard" but fast checker. Or if there is a native version of java regexp matcher that more closely mirrors javascript rules.

olnrao · 2016-02-17T12:25:22Z

Thanks for looking into this and a quick response, huggsboson.

I was not aware of ECMA standard alignment. So, scratch my patch :).

Coming to alternatives, I would like to have following changes (which I
would love to contribute):

For date-time, support min and max values. For example, birth_date field
is a date-time and I want to have min-value as Jan 1, 1900
For timezone, can we represent w/ a more specific data type than just
string?

If both of the above changes are possible (and does not conflict with ECMA
Standard), then I would like to work on those changes.

Two of the patterns we use are actually date patterns :)

Thanks,
Laxmi

On Wed, Feb 17, 2016 at 3:07 AM, huggsboson [email protected]
wrote:

Hi, thanks for the pull request. Sadly the json-schema spec explicitly
dictates that the patterns should be ecma-262 style regexes. Changing to
just use java's pattern matcher will more than likely introduce some
incompatibilities. Maybe if we can dependency inject the pattern matcher
you can have your own "non-standard" but fast checker. Or if there is a
native version of java regexp matcher that more closely mirrors javascript
rules.

—
Reply to this email directly or view it on GitHub
#176 (comment)
.

Laxmi

huggsboson · 2016-03-17T17:35:09Z

I'm trying to think... this feels like something where a native date-time type would do a better job than trying to extend regular expressions. I'm less familiar with what we have already built-in with regards to dates and times, but I believe there is something. (Maybe see if the spec has a reference to dates?)

azzmosphere · 2017-03-08T11:25:48Z

Is this still and issue? I have noticed that the issue has not been commented on since March 2016 and that the latest version of the validator allows for the "format":"date-time" keywords which implements the RFC 3339, section 5.6 interpretation of date time. I am therefore assuming this issue to be no longer relevant.

I tested this with the following code:

{ "$schema" : "http://json-schema.org/draft-04/schema#", "format":"date-time" } ... "2017-01-01T10:10:10.111Z"
and it seemed good, and all though I did not check the speed, judging by @huggsboson comment believe this definitely proves there is something already build-in with regards to dates and times.

sampath-methuku · 2017-03-08T13:08:01Z

This Sampath an engineer who worked with @olnrao, and observed the performance issue with regex pattern matchings. I will run the same test data against new code in a couple of days and will let you know whether performance has really improved or not.

sampath-methuku · 2017-03-09T17:39:02Z

src/main/java/com/github/fge/jsonschema/keyword/validator/common/PatternValidator.java

    public PatternValidator(final JsonNode digest)
    {
+        _patterns = new HashMap<String, Pattern>();
        super("pattern");


super should be the first statement in the constructor, otherwise, compilation fail with

call to super must be first statement in constructor

sampath-methuku · 2017-03-09T20:40:31Z

@olnrao there is compilation issue please fix that,

I have fixed that compilation locally and tested with following.

schema with 3 date patterns, 2 text field patterns ```
"pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-",
"pattern" : "^[+-][0-1][0-9]:[0-5][0-9]$",
"pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-",
"pattern": "[^\s]{1,3000}",
"pattern": "[^\s]{1,200}",


JSON data file had 1000 messages, iterated the same JSON input validation with schema 1000 times.
done the above the exercise with  existing latest version of json-schema-validator i.e 2.2.6 
 and with the fix regex-validation-perf.

we have observed following results.

CPU profiling is done using visual tool

Total Time taken by com.github.fge.jsonschema.keyword.validator.common.PatternValidator.validate() 

with 2.2.6                                  -->  295,955ms
with regex-validation-perf fix  -->      8,000ms

which is a very good improvement in performance,   Attaching the results 

![cpu-profile-with-regex-validation-perf-fix](https://cloud.githubusercontent.com/assets/15689073/23769761/724b61a8-0536-11e7-955c-fc5f46ba2f73.png)

![cpu-profile-with-2 2 6-version](https://cloud.githubusercontent.com/assets/15689073/23769762/724c89ac-0536-11e7-8ecf-2722f4a58b64.png)




[snapshorts.zip](https://github.com/daveclayton/json-schema-validator/files/832246/snapshorts.zip)

sampath-methuku · 2017-03-10T07:29:07Z

The actual issue for which this pull request was raised is,

for regular expression in the schema, pattern matching performance is very poor for this library since it is not storing the compiled pattern of regular expression , for very JSON message validation
code was using regMatch(regex ,text), which is less performance compared to pre-compiled patterns
@olnrao gave performance fix by adding code to compile and store the complied Pattern for regex in a local cache(hashMap) and reusing of this compiled Pattern for all message pattern matching for improving the performance.

we have date-time format fields in our scheme but we want min & max values for this fields.
ex: we want to accept filed
"publishedAt" with date-time values and should be after Unix epoch i.e [1970-01-01 00:00:00],
"format":"date-time" "pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-"
"birthDate" with date-time values and should not be before 1900-01-01 00:00:00
"format":"date-time" "pattern": "^(19[0-9][0-9]|[2-9][0-9][0-9][0-9])-"
"name" text filed should accept only english characters (at least 1 character)
"pattern": "^[a-zA-Z]+$"

the date-time format in the schema can be applied on string type, but there is no native date-time type in json schema.

so basically along with date-time format support in JSON schema we need, min date and max date support in JSON shema,

schema
{ "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "publishedAt": { "type": "string", "format": "date-time", "pattern": "^(19[7-9][0-9]|[2-9][0-9][0-9][0-9])-" }, "birthDate": { "type": "string", "format": "date-time", "pattern": "^(19[0-9][0-9]|[2-9][0-9][0-9][0-9])-" }, "name": { "type": "string", "pattern": "^[a-zA-Z]+$" } } }
mesage
{ "publishedAt": "2010-07-29T17:47:46.000Z", "birthDate": "1920-07-29T17:47:46.000Z", "name": "Raj" }

So I strongly support this fix and recommend fix should go to master branch. Please let me know any thing I have missed here or mis-interpreted.

azzmosphere · 2017-03-10T08:04:02Z

@sampath-methuku aside from the change you mentioned above that fixes the compilation error, "
super("pattern");" I am all for the fix. Compiled regular expressions are much better

sampath-methuku reviewed Mar 9, 2017

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RegEx Validation Using Java Patterns (perf) #176

RegEx Validation Using Java Patterns (perf) #176

olnrao commented Feb 15, 2016

huggsboson commented Feb 16, 2016

olnrao commented Feb 17, 2016

huggsboson commented Mar 17, 2016

azzmosphere commented Mar 8, 2017

sampath-methuku commented Mar 8, 2017

sampath-methuku Mar 9, 2017

azzmosphere Mar 10, 2017

sampath-methuku commented Mar 9, 2017

sampath-methuku commented Mar 10, 2017

azzmosphere commented Mar 10, 2017

RegEx Validation Using Java Patterns (perf) #176

Are you sure you want to change the base?

RegEx Validation Using Java Patterns (perf) #176

Conversation

olnrao commented Feb 15, 2016

huggsboson commented Feb 16, 2016

olnrao commented Feb 17, 2016

huggsboson commented Mar 17, 2016

azzmosphere commented Mar 8, 2017

sampath-methuku commented Mar 8, 2017

sampath-methuku Mar 9, 2017

Choose a reason for hiding this comment

azzmosphere Mar 10, 2017

Choose a reason for hiding this comment

sampath-methuku commented Mar 9, 2017

sampath-methuku commented Mar 10, 2017

azzmosphere commented Mar 10, 2017