-
Notifications
You must be signed in to change notification settings - Fork 516
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
Performance concerns with getHandlerName #41
Comments
@gbutt-tr Would you like to see my version of this in action? I'd appreciate any feedback. |
@gbutt-tr Sorry for the mega-delay. Happy to entertain a PR for this. Thanks! |
Just looked through the history of master, saw this got merged. Im updating mine getHandlerName() to match the above code. |
I use |
@gbutt-tr @kevinohara80 While exploring this repo, saw this issue. Can anyone, guide me to an article or a programming concept that explains why this solution inproves the performence so dramatically? |
The idea, I believe, is that by using Bear in mind that all of this is speculation though, since Apex is a black box for us. |
Great Idea, didn't thought about that. Thank you very much Renato! |
@kevinohara80 if you're interested, I can create a PR for your review.
We have run into performance issues with getHandlerName. Apparently executing String.valueOf(this) can take a long time to execute if the concrete handler class has a lot of data stored as properties (i.e. storing newList and newMap as properties on your handler class). We have reason to believe this has become more of an issue since Summer 22, but I have no hard evidence on that.
The best solution for us was to replace usage of handlerName Strings with Types throughout the framework. When using types
Here are my test results.
Using Types
Using Strings
The text was updated successfully, but these errors were encountered: