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

Remove code repetition in value.js #7358

Merged
merged 2 commits into from
Oct 8, 2018
Merged

Remove code repetition in value.js #7358

merged 2 commits into from
Oct 8, 2018

Conversation

mourner
Copy link
Member

@mourner mourner commented Oct 4, 2018

Made a base class for value classes to remove code repetition and improve clarity.

Launch Checklist

  • briefly describe the changes in this PR
  • write tests for all new functionality already covered
  • document any changes to public APIs
  • post benchmark scores
  • manually test the debug page

@mourner
Copy link
Member Author

mourner commented Oct 4, 2018

image

@ansis
Copy link
Contributor

ansis commented Oct 5, 2018

This looks great to me! I know this area is super performance sensitive and during the first implementation we had something more in this direction and it was reversed after profiling. The paint benchmark looks great but should we do some some more granular profiling?

Copy link
Contributor

@ChrisLoer ChrisLoer left a comment

Choose a reason for hiding this comment

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

Looks great!

src/gl/value.js Outdated
return null;
}
_set(v: any) {
if (this.vao) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking out loud to document the change here...

Before, if we didn't have context.extVertexArrayObject, we would rely on code in context.js to never set this.dirty to true, so we'd never try to bind the object. Now, we don't depend on that code in context.js to keep us from attempting to bind, but it still prevents us from storing any value in this.current (although it also looks like all the calls to bindVertexArrayOES.set also check for the extension before running).

So looks like just one more layer of belt-and-suspenders protection against accidentally using a missing extension. 👍.

setDefault(): void { this.set(this.default); }

set(v: ?WebGLTexture): void {
if (this.dirty || this.current !== v) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Was there a reason that the dirty/inequality check order was reversed here before? I'm not actually sure what the equality operator for WebGLTexture does although it seems unlikely to make any difference that we can now call it more frequently (when the ColorAttachment is dirty).

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the base class set function does the dirty/inequality check before calling each child class' _set function.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think there's no difference — comparing boolean shouldn't be slower than comparing object references.

Copy link
Contributor

Choose a reason for hiding this comment

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

ooh I missed the key word reversed – nvm!

Copy link
Contributor

@mollymerp mollymerp left a comment

Choose a reason for hiding this comment

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

This is a nice simplification! I would also be in favor with some more granular profiling as ansis suggests just to make sure there aren't unexpected effects but this looks good to me!

@mourner
Copy link
Member Author

mourner commented Oct 7, 2018

It looks like the _set/_equals methods don't get inlined for some reason, so while there's a few percent slowdown in profiles which might not reflect on the paint benchmark, I'm not comfortable merging it. So I'll try to find out why V8 doesn't inline, and if it can't be helped, roll back halfway so that at least set methods are written out in full (but the PR will still shave off a lot of repetition).

@mourner
Copy link
Member Author

mourner commented Oct 8, 2018

OK, I reintroduced explicit set methods for each type, which makes it more verbose but still better than master — profiles and Paint benchmark look good.

image

@mourner mourner merged commit 9f4c304 into master Oct 8, 2018
@mourner mourner deleted the dry-value branch October 8, 2018 12:02
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.

4 participants