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

Make special subclass from Parser without expectations. #20

Open
dikmax opened this issue Nov 11, 2015 · 3 comments
Open

Make special subclass from Parser without expectations. #20

dikmax opened this issue Nov 11, 2015 · 3 comments

Comments

@dikmax
Copy link
Contributor

dikmax commented Nov 11, 2015

Some parsers shouldn't have error messages, they always should produce success results. For such parsers caring about expectations is really expensive and unnecessary. Idea is to make some subclass or some flag to exclude everything unneeded. I've tested on my library (just copied and rewrote many, skipMany and choose methods) and parser started working 30% faster.

@polux
Copy link
Owner

polux commented Nov 12, 2015

Sounds like a good idea, although I'm not sure I understand all the implications yet, nor what is the best way to do it. Did you profile your markdown parser using obervatory? If yes, where is this extra time spent after your change to lazy expectation? In CombinedExpectation allocations?

@dikmax
Copy link
Contributor Author

dikmax commented Nov 12, 2015

Actually EmptyExpectation allocation was higher. CombinedExpectation allocation + EmptyExpectation allocation takes around 8-10% of time. But combined with other operations like checking expectations parameter while ParseResult.copy and so on, gives ~30% less time for parsing.

You can check version without expectations here: https://github.com/dikmax/parsers/tree/light-parser

I don't know best way to do this, too. Version above is just to testing.

BTW, after removing expectation most expensive operations become Parser.>> and ParseResult allocation.

@dikmax
Copy link
Contributor Author

dikmax commented Nov 12, 2015

Also removing expectation will give room for additional optimization. For example, we could replace in operator >>:

return res2.copy(
            isCommitted: res.isCommitted || res2.isCommitted);

with

return res2.isCommited == res.isCommitted || res2.isCommitted ? res2 :
        return res2.copy(isCommitted: !res2.isCommited);

That would eliminate ParseResult allocation in really many cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants