Permalink
Browse files

JSON: Fix property and string patterns performance. Fix #1080

  • Loading branch information...
1 parent 23c6e8a commit 0ca1353056abc343f36a1bf0745b51257ad12486 @Golmote Golmote committed Jan 10, 2017
Showing with 8 additions and 8 deletions.
  1. +7 −7 components/prism-json.js
  2. +1 −1 components/prism-json.min.js
@@ -1,11 +1,11 @@
Prism.languages.json = {
- 'property': /"(?:\\.|[^|"])*"(?=\s*:)/ig,
- 'string': /"(?!:)(?:\\.|[^|"])*"(?!:)/g,
- 'number': /\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee][+-]?\d+)?)\b/g,
- 'punctuation': /[{}[\]);,]/g,
- 'operator': /:/g,
- 'boolean': /\b(true|false)\b/gi,
- 'null': /\bnull\b/gi
+ 'property': /"(?:\\.|[^\\"])*"(?=\s*:)/ig,
+ 'string': /"(?!:)(?:\\.|[^\\"])*"(?!:)/g,
+ 'number': /\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee][+-]?\d+)?)\b/g,
+ 'punctuation': /[{}[\]);,]/g,
+ 'operator': /:/g,
+ 'boolean': /\b(true|false)\b/gi,
+ 'null': /\bnull\b/gi
};
Prism.languages.jsonp = Prism.languages.json;
@@ -1 +1 @@
-Prism.languages.json={property:/"(?:\\.|[^|"])*"(?=\s*:)/gi,string:/"(?!:)(?:\\.|[^|"])*"(?!:)/g,number:/\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee][+-]?\d+)?)\b/g,punctuation:/[{}[\]);,]/g,operator:/:/g,"boolean":/\b(true|false)\b/gi,"null":/\bnull\b/gi},Prism.languages.jsonp=Prism.languages.json;
+Prism.languages.json={property:/"(?:\\.|[^\\"])*"(?=\s*:)/gi,string:/"(?!:)(?:\\.|[^\\"])*"(?!:)/g,number:/\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee][+-]?\d+)?)\b/g,punctuation:/[{}[\]);,]/g,operator:/:/g,"boolean":/\b(true|false)\b/gi,"null":/\bnull\b/gi},Prism.languages.jsonp=Prism.languages.json;

4 comments on commit 0ca1353

@mAAdhaTTah
Contributor

@Golmote Because I'm terrible at Regex, I was wondering if you could shed some light as to what this change does and why it resolved the issue in the linked ticket. Thanks!

@Golmote
Contributor

@mAAdhaTTah I'm not even sure I can explain. I think the choices in the alternative should try to exclude each other, which was not the case here, because of (what I assume was) a typo. The \ could be matched by either part of the alternative, thus increasing drastically the number of possibilities. I guess that was leading to a lot of backtracking, which is just terrible for performance.

@Golmote
Contributor

@mAAdhaTTah I remember we encountered similar performance issues in C-like and JS strings, some time ago. And you'll notice the fix actually followed the same reasoning: 476cbf4

@RickyRoller

@Golmote Any chance we could get this in a release? I'd love to get it pulled into our project

Please sign in to comment.