-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
Shopping cart performance enhancements #6011
Conversation
Reformatting - Use null coalescing (??) operator where indicated - Use short array syntax - No one-line conditionals - No one-line multiple assignments Refactoring - Since the `contents` property is keyed on a 'uprid', change the `$products_id` key to be `$uprid` on foreach traversals of that array. - Limit MySQL updates to a single row for unique operations. - Use `===` where warranted. - Use `zen_define_default` where warranted. - Use `strpos` instead of `preg_match` when checking for gift-certificates in the cart. - Remove redundant code. - Use `zen_get_product_details` where warranted to get maximum cached queries. Results in a roughly 50% reduction in time taken to add/remove/update a product as well as the cart's overall calculations! Corrections - `calculate` didn't process a 'base' product pricing if a product wasn't found, but *did* process the attributes! Should the product be removed from the cart if this condition is found?
FWIW, I'm also considering removing the use of |
I've only used it a few times, but it was certainly helpful at the time. If the class had more smaller methods in it it would be even easier to debug when a problem occurred, instead of having to trace through to figure out which block is doing what ... which that $display_debug_messages var was trying to help with, IIRC. |
Agreed on the smaller methods. If the feature has utility, it stays! |
Oy, this is a massive bunch of changes in one commit. Super complex to review. 😨 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Thanks. That's a huge overhaul, optimizing a ton of things.
A couple small bugs highlighted.
Brings back memories of when a bunch of this code was written ... ... shaking my head :D
I believe that I've got all the corrections/comments addressed in the just-pushed update. |
... changes requested for zencart#6011.
... changes requested for zencart#6011.
If you set |
There's only 12 errors, but some may generate a "big-picture" discussion, so it may be prudent to hoist it above the parapet as a separate thing to throw mud at, in the interests of mixing metaphors. |
* Shopping cart performance enhancements Reformatting - Use null coalescing (??) operator where indicated - Use short array syntax - No one-line conditionals - No one-line multiple assignments Refactoring - Since the `contents` property is keyed on a 'uprid', change the `$products_id` key to be `$uprid` on foreach traversals of that array. - Limit MySQL updates to a single row for unique operations. - Use `===` where warranted. - Use `zen_define_default` where warranted. - Use `strpos` instead of `preg_match` when checking for gift-certificates in the cart. - Remove redundant code. - Use `zen_get_product_details` where warranted to get maximum cached queries. Results in a roughly 50% reduction in time taken to add/remove/update a product as well as the cart's overall calculations! Corrections - `calculate` didn't process a 'base' product pricing if a product wasn't found, but *did* process the attributes! Should the product be removed from the cart if this condition is found? * Updating based on review comments
Reformatting
Refactoring
contents
property is keyed on a 'uprid', change the$products_id
key to be$uprid
on foreach traversals of that array. That makes it more obvious when viewing the code as to what thecontents
array is keyed on.===
where warranted.zen_define_default
where warranted.strpos
instead ofpreg_match
when checking for gift-certificates in the cart.zen_get_product_details
where warranted to get maximum cached queries. Results in a roughly 50% reduction in time taken to add/remove/update a product as well as the cart's overall calculations!Corrections
calculate
didn't process a 'base' product pricing if a product wasn't found, but did process the attributes! Should the product be removed from the cart if this condition is found?