Pull a request for an open source PHP project on GitHub yesterday
I changed a common Core function in the common library to first determine if config is enabled.
Determine if n config is enabled in method after the load class is determined instead of load
I think there's a lot of efficiency in this area.
After submission owner replied that he understood that my starting point was efficiency but this judgment should be left to the class to deal with.
All right, I thought, "Look clean," but for that reason, you can abandon efficiency?
That function is called at least 15 times for a single request. It's unreasonable for me.
I'm not going to argue, after all, it's someone else's project, but it's kinda tangled.
I feel good about my own code quality started two times PR have been merged by owner
The last reason to be close is the same as above please do not worry thank you.
Reply content:
In performance optimization, there is a sentence, that is, before performance is not obvious problems, do not optimize, because the performance of the optimization will often affect the decoupling and reusability of the Code
As for the specific example of the main problem, do not make a comment, after all, do not see the specific code you are writing less code. The low-coupling scalability of a simple design is far more important than a little efficiency. What do you think is wrong to optimize, you know "premature optimization is the root of all evil" this sentence?
By the way: when does PHP still care about the efficiency of this implementation? is the design pattern not designed to improve efficiency? (Design patterns are a set of programming methods for long-term program workers to improve development efficiency and program execution efficiency, in which case
changes should be made according to the project requirements and specific implementation of the project！ Design patterns are important when efficiency is not a bottleneck. Obviously the efficiency problem must be disposed of in advance, but I disagree with you about the example of the config problem.
I can't say the exact reason, but it's right to call config inside the method. It is impossible to have a great effect on efficiency. You may rarely do performance testing.
This performance optimization, in the performance test report is completely invisible, you this optimization is equivalent to a person to lose weight, and the nose hair to cut, can not say you have no effect, but there is no meaning, not worth paying for the cost of design mode more important
Design pattern is a summary of experience
Most of the time, it inevitably goes to design mode
If it's bad, it just means you don't understand the wrong place.
and performance problems are often the product of imagination.
The performance out of the actual scene is meaningless.
And the landlord's problem seems to be taken for granted in advance optimization
Systems built according to design patterns
We all have the ability to read and optimize performance.
Systems built to optimize local performance in advance
I didn't even want to touch it. Code efficiency first, operating efficiency in 99% of the environment is not a problem. Readability, maintainability the general priority is before the efficiency of the operation. It's really a serious problem. Optimized for specific 1% to 10% parts
