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

perf: improve performance of purpose restriction encoder [encode] #424

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

marco-prontera
Copy link
Contributor

The goal of this PR is to improve performance of purpose restriction encoder.
Here a link to check https://codesandbox.io/s/tender-colden-nzmdc6

ps: @sevriugin This is an addition to the last PR that was merged but I didn't have time to update it before it was merged into master. Since the new version hasn't been released yet I think we're in time to merge it

@achimschloss
Copy link

achimschloss commented Sep 26, 2023

@marco-prontera quick remark - did not follow up on this given you patched it. Your original new implementation only broke I think because during encoding

tcModel = tcModel.clone();
resets the GVL filter during encoding (the check of the ranges against the GVL failed).

I assume this should not happen with clone but had not time to think about it, not do it get why the clone is done anyhow

@marco-prontera
Copy link
Contributor Author

marco-prontera commented Oct 27, 2023

@marco-prontera quick remark - did not follow up on this given you patched it. Your original new implementation only broke I think because during encoding

tcModel = tcModel.clone();

resets the GVL filter during encoding (the check of the ranges against the GVL failed).
I assume this should not happen with clone but had not time to think about it, not do it get why the clone is done anyhow

@asr-enid Can you prove what you say through PR?
Unfortunately I don't have much time so if you can open a PR it's the only way for me

@marco-prontera marco-prontera changed the title perf: improve performance of purpose restriction encoder perf: improve performance of purpose restriction encoder [encode] Dec 14, 2023
@marco-prontera
Copy link
Contributor Author

Hi @sevriugin, I have updated the PR adding a further improvement in encoding performance with the use of pub restrictions. Essentially it involves skipping useless loops with vendorIds that aren't there, this ensures we avoid causing long JS tasks that could negatively impact the new Google INP metric.
e.g.: A publisher who uses vendors with very "distant" IDs such as 100 to 4000 with this improvement the encode process would avoid many iterations by reducing the work to the bare minimum.

@sevriugin
Copy link
Collaborator

@marco-prontera Thanks Marco, I will take a look

@marco-prontera
Copy link
Contributor Author

Hi @sevriugin could you review this, please?

@marco-prontera
Copy link
Contributor Author

Can you review?


return nextId;
if (lastIndex - firstIndex > 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could this one be true if first index is equal -1 -> not found?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes that condition is required only to check if we are at the "end" of the used GVL vendor list in fact in line 26 you see we are taking the nextIndex the one that is specified in the GVL vendor list.
This makes possible to skip every extra loop in the purpose restriction encode process.


}
const nextIndex = gvlVendorIds.indexOf(vendorId + 1);
Copy link
Collaborator

Choose a reason for hiding this comment

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

vendorId + 1 could be out of range if vendorId is the last vendor in the GVL, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the vendorId is the last vendor in the GVL this block won't be executed, in fact the vendorId is the latest this function will return itself as "special case". See return statement at line 35


const {nextVendorId, index} = nextGvlVendor(vendorId, vendors[len - 1]);

if (vendors[i + 1] > nextVendorId) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

vendors[i+1] is always defined ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, in fact if it is not defined the relevant block of code will not be executed. See the condition at line 74 and the condition at line 61

@sevriugin
Copy link
Collaborator

@marco-prontera added some question? hope it makes sense, cheers

Copy link
Contributor Author

@marco-prontera marco-prontera left a comment

Choose a reason for hiding this comment

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

@sevriugin Hope everything makes sense to you. I've been using this optimisation for about 7 months without any problem. Previously if you remember I introduce more tests for this part that enables us to do this types of changes.

Let me know, I'd love to help even more


const {nextVendorId, index} = nextGvlVendor(vendorId, vendors[len - 1]);

if (vendors[i + 1] > nextVendorId) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, in fact if it is not defined the relevant block of code will not be executed. See the condition at line 74 and the condition at line 61


}
const nextIndex = gvlVendorIds.indexOf(vendorId + 1);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the vendorId is the last vendor in the GVL this block won't be executed, in fact the vendorId is the latest this function will return itself as "special case". See return statement at line 35


return nextId;
if (lastIndex - firstIndex > 0) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes that condition is required only to check if we are at the "end" of the used GVL vendor list in fact in line 26 you see we are taking the nextIndex the one that is specified in the GVL vendor list.
This makes possible to skip every extra loop in the purpose restriction encode process.

@sevriugin
Copy link
Collaborator

Ok, thanks for explanation, LGTM

Copy link
Collaborator

@HeinzBaumann HeinzBaumann left a comment

Choose a reason for hiding this comment

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

This looks good to me.

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