Speed up line/column in OffsetPosition #68
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Building the index again and again for every OffsetPosition instance makes very little sense. So this makes it build it only once for a given source. I'm not sure if this is the best way to implement it and I'm afraid that a global synchronized map may be a performance bottleneck once the number of processors goes into the hundreds, but I know very little Scala/Java to do this properly. :-( Fixes http://stackoverflow.com/questions/14707127/accessing-position-information-in-a-scala-combinatorparser-kills-performance
This should scale much better.
|
Any idea what to do with the mima errors? Shall I use a differently named object with package-private members or are those warnings false? |
|
That's why I was more into the re-submission of the PR, cherry-picking into 1.0.x seemed too good to be true... Hmm, this is one of those annoying things with the companion object of a case class. I think that adding |
|
Oh, that indeed fixes it! I would never have figured that out myself. :-) |
gourlaysama
added a commit
that referenced
this pull request
Sep 11, 2015
Speed up line/column in OffsetPosition
gourlaysama
added a commit
to gourlaysama/scala-parser-combinators
that referenced
this pull request
Sep 20, 2016
This commit backports the commit below, with two caveats: - the fix in scala#68 doesn't work with Scala.js, so it is only enabled on the JVM for now - the scalaVersion/crossScalaVersion madness breaks the sbt build in 1.0.x (it didn't in master for some reason), so the second backport commit below had to be squashed with this one [backport] Add support for Scala.js, with cross-compilation. Scala versions were upgraded to 2.11.7 and 2.12.0-M3. 2.12 is only used when running the build on JDK8 or later. JavaTokenParsers.identifier was rewritten not to use a regexp, but rather primitive parsers and Character.isJavaIdentifier{Start,Part}. The regexp-based implementation relies on Java-specific character ranges. JavaTokenParsers.stringLiteral was slightly adapted with an expansion of `\p{Cntrl}` into `[\x00-\x1F\x7F]`. The former character range is Java-specific. We also removed an invalid (and useless) `+` at the end of the regexp. The test t4929.scala is JVM-only. (Author: Sébastien Doeraene <[email protected]>) (cherry picked from commit 98737a2) --- [backport] set Scala version in a more dbuild-friendly way having scalaVersion and crossScalaVersions set in different places was confusing dbuild needed to fix scala/community-build#215 (Author: Seth Tisue <[email protected]>) (cherry picked from commit bde222c)
gourlaysama
added a commit
to gourlaysama/scala-parser-combinators
that referenced
this pull request
Sep 20, 2016
This commit backports the commit below, with two caveats: - the fix in scala#68 doesn't work with Scala.js, so it is only enabled on the JVM for now - the scalaVersion/crossScalaVersion madness breaks the sbt build in 1.0.x (it didn't in master for some reason), so the second backport commit below had to be squashed with this one [backport] Add support for Scala.js, with cross-compilation. Scala versions were upgraded to 2.11.7 and 2.12.0-M3. 2.12 is only used when running the build on JDK8 or later. JavaTokenParsers.identifier was rewritten not to use a regexp, but rather primitive parsers and Character.isJavaIdentifier{Start,Part}. The regexp-based implementation relies on Java-specific character ranges. JavaTokenParsers.stringLiteral was slightly adapted with an expansion of `\p{Cntrl}` into `[\x00-\x1F\x7F]`. The former character range is Java-specific. We also removed an invalid (and useless) `+` at the end of the regexp. The test t4929.scala is JVM-only. (Author: Sébastien Doeraene <[email protected]>) (cherry picked from commit 98737a2) --- [backport] set Scala version in a more dbuild-friendly way having scalaVersion and crossScalaVersions set in different places was confusing dbuild needed to fix scala/community-build#215 (Author: Seth Tisue <[email protected]>) (cherry picked from commit bde222c)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Building the index again and again for every OffsetPosition instance makes
very little sense. So this makes it build it only once for a given source.
I'm not sure if this is the best way to implement it and I'm afraid that a
global synchronized map may be a performance bottleneck once the number of
processors goes into the hundreds, but I know very little Scala/Java to do
this properly. :-(
Fixes
http://stackoverflow.com/questions/14707127/accessing-position-information-in-a-scala-combinatorparser-kills-performance