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

CharMatcher static init is long #1192

Closed
gissuebot opened this issue Oct 31, 2014 · 4 comments
Closed

CharMatcher static init is long #1192

gissuebot opened this issue Oct 31, 2014 · 4 comments
Assignees
Milestone

Comments

@gissuebot
Copy link

gissuebot commented Oct 31, 2014

Original issue created by travis.downs on 2012-11-06 at 03:18 AM


CharMatcher does a lot of work in static init, including creating a 65k element (where elements are "bits") and calling CharMatcher.match() for every codepoint on a complex matcher.

The worst offender is:

public static final CharMatcher INVISIBLE =

...

 .precomputed();

which does the aforementioned work. This takes maybe 50ms in the best base, but can take > 10 seconds in pathological cases, as described here:

http://stackoverflow.com/questions/13143401/guava-charmatcher-static-initialization-slow

People who never use the static members of CharMatcher, or even who never use CharMatcher at all (but it gets indirectly referred to by other Guava code) pay this price.

In addition to speeding up the underlying table creation (perhaps with an optimized, non-fluent version of the matchers for things like INVISIBLE), it would be great if these singletons were created lazily, so you don't pay the cost until they are used - very useful for things like INVISIBLE which are probably rarely used. This could be accomplished by having a char matcher which internally delegates to some underlying matcher, but constructs the underlying lazily.

@gissuebot
Copy link
Author

gissuebot commented Nov 1, 2014

Original comment posted by kevinb@google.com on 2012-11-07 at 01:36 AM


What it does is is pretty bad indeed. We're on it.


Status: Accepted

@gissuebot
Copy link
Author

gissuebot commented Nov 1, 2014

Original comment posted by kak@google.com on 2012-11-07 at 01:44 AM


(No comment entered for this change.)


Status: Started
Owner: lowasser@google.com
Labels: Package-Base

@gissuebot
Copy link
Author

gissuebot commented Nov 1, 2014

Original comment posted by lowasser@google.com on 2012-11-07 at 05:06 PM


Submitted internally; should be mirrored out soonish.


Status: Fixed
Labels: Milestone-Release14

@gissuebot
Copy link
Author

gissuebot commented Nov 1, 2014

Original comment posted by kevinb@google.com on 2013-01-30 at 07:08 AM


We might want to explain what we fixed. Is all precomputing() lazy now?

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

No branches or pull requests

3 participants