-
Notifications
You must be signed in to change notification settings - Fork 21
Parser Combinators - parsing String is worse than StringReader #8542
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
Comments
Imported From: https://issues.scala-lang.org/browse/SI-8542?orig=1
|
@soc said: |
@dcsobral said: If that's the case, then it's simply a matter of finding intances of substringing in the code, or simply introducing the workaround of always using |
Alexander Abdugafarov (frozenspider) said: parseAll(new StringReader(String))
For 100 items: 12 ms
For 500 items: 48 ms
For 1000 items: 64 ms
For 5000 items: 157 ms
For 10000 items: 147 ms
For 50000 items: 1470 ms
===
parseAll(String)
For 100 items: 0 ms
For 500 items: 2 ms
For 1000 items: 4 ms
For 5000 items: 17 ms
For 10000 items: 49 ms
For 50000 items: 186 ms |
@gourlaysama said (edited on Apr 28, 2014 6:08:46 PM UTC): I am closing this one as a duplicate of #7710. |
When parsing
s: String
, usingparseAll(p, new java.io.StringReader(s))
is much, much more efficient than using justparseAll(p, s)
- difference in runtime's order of growth is stunning.I've encoutered this while working on my project, so this is a real-world problem.
I've made sort of a benchmark from it, it is attached to the issue. Here are the results for me:
P.S.
Btw, gap between 10,000 and 50,000 is strange
Duplicate of #7710.
The text was updated successfully, but these errors were encountered: