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

Introduce performance optimizations and new INP metric #436

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

Conversation

marco-prontera
Copy link
Contributor

closes #435

The goal of this PR is to introduce a way to allow users of this library to make use of some optimizations that can be made.

This will help us improve INP metrics since the nature of a CMP is very much linked to the new metric, it would also allow us to ensure a better user experience overall.

Here the article where INP is explained https://web.dev/articles/inp

Just let me know if you need some screenshots.
@sevriugin Hope in a review soon, thanks in advance

// this will enable you to skip the TCString.decode call
// decodeWithCache if set to true it will call the TCString.decode using the previously TCModel decoded in cache
// this skip a lot of works
cmpApi.update(encodedTCString, false, {preDecodedTCModel: null, decodeWithCache: false});
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am not sure we can change api without discussion and approval, also these parameters are looks very complicated to manage, is it possible to make this improvement always running or it does not make sense for all cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The purpose of this additional parameter is not to introduce breaking changes, since in any case the first two parameters that were already used do not change. Honestly, I was careful not to introduce breaking changes to avoid behaviors that those who already use the library might not expect, but we can also evaluate other solutions. Honestly, I haven't introduced mechanisms or classes to avoid adding weight and complexity to the project, but I don't think it's a problem

@sevriugin
Copy link
Collaborator

We have implemented this maybe we can reuse some ideas here

@marco-prontera
Copy link
Contributor Author

We have implemented this maybe we can reuse some ideas here

Are you saying to do a similar thing for all the places where I applied memoization?

@HeinzBaumann
Copy link
Collaborator

We have implemented this maybe we can reuse some ideas here

I like this implementation a lot better. It does the caching without the need to change any APIs, which is much preferred.

@HeinzBaumann
Copy link
Collaborator

There is also this open PR suggesting improvements to the performance to the pub restrictions code: #424 .

@marco-prontera
Copy link
Contributor Author

marco-prontera commented Dec 19, 2023

We have implemented this maybe we can reuse some ideas here

I like this implementation a lot better. It does the caching without the need to change any APIs, which is much preferred.

So you say to apply the advice suggested by @sevriugin?
I added parameters to the APIs to make it possible to decide whether or not to use memoization techniques. Since in the event that a new instance of the TCModel created from the decode of a TCString is necessary, users of the library still have the opportunity to do so. Besides this the addition of these parameters does not change the current behavior so no breaking change is introduced.
While if I were to apply the advice suggested, users would be forced to use the clone method to obtain an identical instance of a TCModel. For the use I make of it, honestly I'm fine with having default caching (as suggested), I just want to apply the right choice to avoid possible problems for some users and not introduce breaking changes.

Tell me if you want me to apply the solution suggested by @sevriugin and I will update the PR, otherwise if you have other suggestions we can think about it

@marco-prontera
Copy link
Contributor Author

Can you review?

@sevriugin
Copy link
Collaborator

We have testes this one didomi#4 for more then one year so it will be save to apply and no action needed from library users to use this feature, imo, it's better do not change API if we can avoid it, hope it makes sense

@marco-prontera
Copy link
Contributor Author

We have testes this one didomi#4 for more then one year so it will be save to apply and no action needed from library users to use this feature, imo, it's better do not change API if we can avoid it, hope it makes sense

I will apply the same changes considering that in this PR there are additional improvements in this PR, thanks for the advice 🙏 I will update you asap

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.

Introduce performance optimizations and new INP metric
3 participants