Skip to content
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

After upgrading to 3.0, the performance is greatly reduced #51

Open
DuShuYuan opened this issue Apr 3, 2024 · 10 comments
Open

After upgrading to 3.0, the performance is greatly reduced #51

DuShuYuan opened this issue Apr 3, 2024 · 10 comments
Labels
possible-bug Could be a bug

Comments

@DuShuYuan
Copy link

When running in WebWorder, it takes about 4 seconds to parse the same SQL statement (Oracle) in version 2.0 and about 15 seconds in version 3.0

My code:

    this._charStream = CharStream.fromString(input);
    this._lexer = new PlSqlLexer(this._charStream);
    this._lexer.removeErrorListeners();
    this._lexer.addErrorListener(new ParseErrorListener(this._parseErrors));

    this._tokenStream = new CommonTokenStream(this._lexer);

    this._parser = new PlSqlParser(tokenStream);

    parser.removeErrorListeners();
    parser.addErrorListener(new ParseErrorListener(this._parseErrors));
    console.time('root');
    // @ts-ignore
    this._parseTree = this._parser.root();
    console.timeEnd('root');

SQL statement tested: ORACLE's package SYS. DIUTIL

If a larger SQL is larger, the webworker will be automatically stopped, and the webwoker will be automatically recycled when it resolves to about 18,000 tokens in 2.0, and can only be resolved to 5,000 tokens in 3.0

I feel that the 3.0 version of the token will take up more memory

SQL statement tested: ORACLE's package SYS. STANDARD

@DuShuYuan

This comment was marked as duplicate.

@DuShuYuan

This comment was marked as duplicate.

@DuShuYuan
Copy link
Author

parser.zip
image

@mike-lischke mike-lischke added the possible-bug Could be a bug label Apr 3, 2024
@mike-lischke
Copy link
Owner

mike-lischke commented Apr 7, 2024

Webworkers are indeed slower. In my benchmark repository I had code to run the benchmarks in webworkers, a while back, and found they ran only half as quick as in the main thread. Not sure what I could do about it.

@mike-lischke
Copy link
Owner

@DuShuYuan In the attached code you used STANDARD as input, but your report is about DUITL, right? I'm asking because the STANDARD input needs forever to lex. I stopped the test after a couple of minutes.

When I limit the STANDARD input to the first 66 lines (576 tokens) it takes a bit more than 4 seconds to do a cold lexer run. DUTIL is lexed in 4.6 seconds for me (618 tokens). So, that seems to be in the range you expect, correct?

Can you try with the latest release again and compare that?

@mike-lischke mike-lischke added the need feedback Awaiting a response from a participant label Apr 7, 2024
@DuShuYuan
Copy link
Author

a
b

demo with webworker:
Test.zip

@DuShuYuan
Copy link
Author

In the unit test, version 2.0 actually took 25 seconds to parse!
And it's all tested diutil.
image

Version 3.0 takes 12s to complete
image

@mike-lischke
Copy link
Owner

mike-lischke commented Apr 10, 2024

Hmm, so version 3.0 is twice as fast (12s vs 26s). Isn't that the opposite of what you report above?

@DuShuYuan
Copy link
Author

Hmm, so version 3.0 is twice as fast (12s vs 26s). Isn't that a good thing?

In WebWorker 2.0 is faster (6s), Target 2015 even takes less than 3s

@DuShuYuan
Copy link
Author

DuShuYuan commented Apr 10, 2024

a b

demo with webworker: Test.zip

I think the most common use case is in webworkers.

You can take a look at the output of this demo.
src/app/lib/readme.md has a description for the 2015 version

@mike-lischke mike-lischke removed the need feedback Awaiting a response from a participant label Apr 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possible-bug Could be a bug
Projects
None yet
Development

No branches or pull requests

2 participants