antlr4ng - npm Package Compare versions
Comparing version 3.0.0 to 3.0.1
@@ -64,2 +64,3 @@ import { Token } from "./Token.js"; | ||
| type: number; | ||
| mode: number; | ||
| /** The start column of the current token (the one that was last read by `nextToken`). */ | ||
@@ -84,5 +85,5 @@ protected currentTokenColumn: number; | ||
| more(): void; | ||
| mode(m: number): void; | ||
| pushMode(m: number): void; | ||
| popMode(): number; | ||
| get modeStack(): number[]; | ||
| /** | ||
@@ -89,0 +90,0 @@ * By default does not support multiple emits per nextToken invocation |
| { | ||
| "name": "antlr4ng", | ||
| "version": "3.0.0", | ||
| "version": "3.0.1", | ||
| "type": "module", | ||
@@ -55,3 +55,3 @@ "description": "Alternative JavaScript/TypeScript runtime for ANTLR4", | ||
| "generate-runtime-tests": "antlr-tgen --config tests/fixtures/config.json", | ||
| "build-bundle": "esbuild ./src/index.js --main-fields=module,main --bundle --target=esnext --external:immutable --keep-names", | ||
| "build-bundle": "esbuild ./src/index.js --main-fields=module,main --bundle --target=esnext --keep-names", | ||
| "build-mjs": "npm run build-bundle -- --outfile=dist/index.mjs --format=esm", | ||
@@ -58,0 +58,0 @@ "build-cjs": "npm run build-bundle -- --outfile=dist/index.cjs --format=cjs", |
@@ -140,5 +140,5 @@ [](https://github.com/mike-lischke/antlr4ng/actions/workflows/nodejs.yml) | ||
| The following table shows the results of the benchmarks that were executed in the [antlr4wasm project](https://github.com/mike-lischke/antlr4wasm/tree/master/benchmarks/mysql). The column for antlr4ng, howevever, contains the current results of this runtime. | ||
| The following table shows the results of the benchmarks that were executed in the [antlr4wasm project](https://github.com/mike-lischke/antlr4wasm/tree/master/benchmarks/mysql). The column for antlr4ng, however, contains the current results of this runtime. | ||
| | | C++ |antlr4ng|antlr4|antlr4ts|antl4wasm| | ||
| | | C++ |antlr4ng|antlr4|antlr4ts|antlr4wasm| | ||
| |---:|---:|---:|---:|---:|---:| | ||
@@ -167,3 +167,3 @@ |Query Collection (cold)|1340 ms| <ins>184/2160 (2344) ms</ins>| 7984 ms| 3402 ms| 3331 ms| | ||
| Since the Java runtime tests have been ported to TypeScript there's another set of benchmarks, the lexer speed test. This set of tests was created when Unicode support landed in ANTLR4 and measures the speed of lexing different Unicode lexems in a lexer generated from the Java grammar. | ||
| Since the Java runtime tests have been ported to TypeScript there's another set of benchmarks, the lexer speed test. This set of tests was created when Unicode support landed in ANTLR4 and measures the speed of lexing different Unicode lexemes in a lexer generated from the Java grammar. | ||
@@ -210,5 +210,9 @@ The original Java execution times have been taken on OS X with a 4 GHz Intel Core i7 (Java VM args: `-Xms2G -Xmx8g`): | ||
| ### 3.0.1 | ||
| Had to make `Lexer.modeStack` public again and allow reading and writing the current lexer mode. | ||
| ### 3.0.0 | ||
| This release completes the conversion of the Java (and JavaScript) ANTRL4 runtime to TypeScript. It's a significant improvement over the existing TS (and JS) runtimes, as it includes now all relevant parts from the Java runtime and has been optimized for performance. It's now twice as fast for cold runs and 20% faster with a warm parser/lexer. See also the benchmark section below. | ||
| This release completes the conversion of the Java (and JavaScript) ANTLR4 runtime to TypeScript. It's a significant improvement over the existing TS (and JS) runtimes, as it includes now all relevant parts from the Java runtime and has been optimized for performance. It's now twice as fast for cold runs and 20% faster with a warm parser/lexer. See also the benchmark section below. | ||
@@ -227,3 +231,3 @@ This makes it the fastest TypeScript (and JS) runtime currently available. The ANTLR4 JavaScript runtime still is slightly faster in short time tests (e.g. 228ms vs 223ms for the query collection test), where system load and other factors have however much more impact compared to tests that run around 10 seconds. | ||
| - The hash implementation (MurmurHash) has been stripped down to the minimum required code to keep this hot path fast as well. | ||
| - Hash codes are now cached whereever possible. | ||
| - Hash codes are now cached wherever possible. | ||
| - The `instanceof` operator is relatively expensive, so it was replaced with checks using a member discriminator in hot paths, where possible (e.g. transition and ATN state types). | ||
@@ -242,3 +246,3 @@ - `Switch` statements in hot paths have been replaced by factory arrays that reduce determination what to create to a simple array value lookup. | ||
| - Runtime tests have been ported to TypeScript, so they can be debugged and provide a much quicker turnaround. | ||
| - Benchmarks now take seperated measurements for lexer and parser runs, which much better shows how high the impact of predicates and actions in the lexer is (e.g. 2/3 of the time in the large inserts benchmark is used for lexing input). | ||
| - Benchmarks now take separated measurements for lexer and parser runs, which much better shows how high the impact of predicates and actions in the lexer is (e.g. 2/3 of the time in the large inserts benchmark is used for lexing input). | ||
| - The release build is no longer minified (and hence larger than before) to avoid trouble with other build tools like terser or webpack. | ||
@@ -251,3 +255,3 @@ | ||
| - The bit set class used bigint to store the values, which is a problem with bundlers like webpack that have no support for bigint. For this reason that type has been replaced (PR #40 feat: replace bigint and BigUint64Array). | ||
| - The bundle is no longer minified and hence larger than before. Bundling a minfied bundle with other bundlers (like terser) in dependent projects might cause trouble. Additionally, minifying a bundle has no benefit in execution time, it's just a size difference (related bugs: #31, #34, #38). | ||
| - The bundle is no longer minified and hence larger than before. Bundling a minified bundle with other bundlers (like terser) in dependent projects might cause trouble. Additionally, minifying a bundle has no benefit in execution time, it's just a size difference (related bugs: #31, #34, #38). | ||
@@ -254,0 +258,0 @@ ### 2.0.10 |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Improved metrics
- Total package byte prevSize
- increased by0.01%
1270235
- Lines of code
40861
- Number of lines in readme file
- increased by1.14%
354