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

Fix upper group limit in GroupedTag #2996

Merged
merged 5 commits into from
Jan 31, 2020
Merged

Fix upper group limit in GroupedTag #2996

merged 5 commits into from
Jan 31, 2020

Conversation

kitten
Copy link
Member

@kitten kitten commented Jan 30, 2020

Fix #2994
Fix #2979

Previously the formula for increasing the size of Uint32Arrays
in the GroupedTag was a little aggressive and would cut of very
short of 2^31 groups. Instead it would cut off between 2^12 and
2^13 components, which isn't quite a lot.

This new upper boundary is the absolute limit of how many slots
a Uint32Array is defined to be able to hold. After this limit we'll
see an error.

Instead of letting this error leak out we now throw a more clear
error that hints at this limitation.

I've also refactored dom.js to finally use throwStyledError as well.

Tests have been updated to reflect all changes.

@kitten kitten requested a review from quantizor January 30, 2020 05:13
@kitten kitten changed the title Fix/upper group limit Fix upper group limit in GroupedTag Jan 30, 2020

/** Create a GroupedTag with an underlying Tag implementation */
export const makeGroupedTag = (tag: Tag): GroupedTag => {
return new DefaultGroupedTag(tag);
};

const BASE_SIZE = 1 << 8;
const BASE_SIZE = 1 << 9;
Copy link
Member Author

@kitten kitten Jan 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've increased the base-size here since I find it highly likely that a lot of apps will actually have around 512 components usually. Larger apps will of course see this grow as usual

let newSize = oldSize;
while (group >= newSize) {
newSize <<= 1;
if (newSize < 0) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works because eventually we'll hit 1 << 31 the upper limit of SMIs, where we overflow into the signed bit, which turns newSize negative.

quantizor
quantizor previously approved these changes Jan 30, 2020
Copy link
Contributor

@quantizor quantizor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me, let's throw up a build on the "test" tag

Previously the formula for increasing the size of Uint32Arrays
in the GroupedTag was a little aggressive and would cut of very
short of 2^31 groups. Instead it would cut off between 2^12 and
2^13 components, which isn't quite a lot.

This new upper boundary is the absolute limit of how many slots
a Uint32Array is defined to be able to hold. After this limit we'll
see an error.

Instead of letting this error leak out we now throw a more clear
error that hints at this limitation.
We can make it easier to track the offending
dynamic components in development by adding another
SMI overflow check to the GroupIDAllocator
@kitten
Copy link
Member Author

kitten commented Jan 30, 2020

This is published as the prerelease 5.0.0-testgrouplimit.0 under the test tag.

quantizor
quantizor previously approved these changes Jan 30, 2020
Copy link
Contributor

@quantizor quantizor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@quantizor
Copy link
Contributor

@kitten throw a changelog entry in there too when you get a moment :)

This was referenced Apr 9, 2020
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

Successfully merging this pull request may close these issues.

Low limit of groups throws error (around 5888) getStyleTags method very slow in v5
2 participants