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

Speed up line/column in OffsetPosition #68

Merged
merged 3 commits into from Sep 11, 2015

Conversation

Projects
None yet
2 participants
@liskin
Copy link
Contributor

commented Sep 11, 2015

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

liskin added some commits Jul 3, 2015

Speed up line/column in OffsetPosition
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
Use a thread local WeakHashMap instead of synchronized
This should scale much better.
@liskin

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2015

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?

@gourlaysama

This comment has been minimized.

Copy link
Member

commented Sep 11, 2015

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 extends scala.runtime.AbstractFunction2[CharSequence,Int,OffsetPosition] to the object should be enough (untested; running sbt test will invoke mima). Sorry about the added process, I guess I could I done that myself...

@liskin

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2015

Oh, that indeed fixes it! I would never have figured that out myself. :-)

@gourlaysama

This comment has been minimized.

Copy link
Member

commented Sep 11, 2015

Yay! That's one of those things that one only remembers because of the pain it caused in the past (for reference, SI-4808 and SI-3664).

LGTM

gourlaysama added a commit that referenced this pull request Sep 11, 2015

Merge pull request #68 from liskin/offsetposition-index-cache
Speed up line/column in OffsetPosition

@gourlaysama gourlaysama merged commit 4600c5a into scala:1.0.x Sep 11, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@liskin liskin deleted the liskin:offsetposition-index-cache branch Sep 12, 2015

gourlaysama added a commit to gourlaysama/scala-parser-combinators that referenced this pull request Sep 20, 2016

[backport] Scala.js support for 1.0.x
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 <sjrdoeraene@gmail.com>)
(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-builds#215

(Author: Seth Tisue <seth@tisue.net>)
(cherry picked from commit bde222c)

gourlaysama added a commit to gourlaysama/scala-parser-combinators that referenced this pull request Sep 20, 2016

[backport] Scala.js support for 1.0.x
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 <sjrdoeraene@gmail.com>)
(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-builds#215

(Author: Seth Tisue <seth@tisue.net>)
(cherry picked from commit bde222c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.