PHP RFC: Code optimizations
- Version: 0.1
- Date: 2023-03-01
- Author: Max Kellermann, max.kellermann@ionos.com
- Status: Withdrawn
- First Published at: http://wiki.php.net/rfc/code_optimizations
Introduction
According to https://github.com/php/php-src/blob/master/CONTRIBUTING.md, pull requests are only allowed for three things:
- add tests
- fix bugs
- implement RFCs
This policy does not allow pull requests to do the following improvements to PHP:
- add documentation
- code cleanup/refactoring
- code optimizations
Requiring a RFC for each such improvement delays everything by at least four weeks, and adds a lot of bureaucracy. This bureaucracy scares away contributors, and effectively prevents small incremental improvements to the PHP code base.
The following are examples of pull requests that have been mistakenly accepted even though they did not fix a bug nor was there a RFC:
This RFC attempts to establish a framework that allows such improvements.
Proposal
To reduce the barrier for small incremental improvements that are not bug fixes, I propose to allow certain code optimizations without having to go through the RFC process.
By “code optimizations”, I mean both optimized for machines (improving the build process and runtime behavior, e.g. by reducing overhead / resource consumption) and humans (improving code readability and maintainability).
Backward Incompatible Changes
No change to the PHP language, therefore no PHP-level incompatible changes.
Some types of code refactoring may lead to incompatible changes to the internal API at the C level.
Proposed PHP Version(s)
“master” branch.
Ideally, “master” should always be able to merge small incremental improvements.
RFC Impact
To SAPIs
Only if internal C APIs get changed.
To Existing Extensions
Only if internal C APIs get changed.
To Opcache
Only if internal C APIs get changed.
New Constants
Not applicable.
php.ini Defaults
Not applicable.
Open Issues
Unaffected PHP Functionality
The PHP language is completely unaffected.
Future Scope
Not applicable.
Proposed Voting Choices
Primary vote (requires supermajority):
- Should small incremental code optimizations that do not change functionality be allowed without a dedicated RFC? Yes/No
(If the primary vote is declined, then such code changes will continue to be disallowed, and PRs without bugfix and without RFC never be approved.)
Secondary votes (requires simple majority):
- Allow adding (API) documentation and code comments? Yes/No
- Allow adding assertions and other debug-mode aids? Yes/No
- Allow improving const-correctness? Yes/No
- Allow moving variable declarations to where they are used first? Yes/No
- Allow fixing compiler warnings and enabling more compiler warnings? Yes/No
- Allow code refactoring that gives the compiler more insight to allow it to detect potential bugs? (e.g. using enums instead of bare integers) Yes/No
- Allow code refactoring that makes code more robust? (e.g. enforce “unsigned char” at the function prototype level to avoid underflows with negative chars) Yes/No
- Allow fixing signedness and integer sizes? (e.g. using size_t where applicable, not using signed integers for counts) Yes/No
- Allow splitting large functions? Yes/No
- Allow splitting largs source files/headers? Yes/No
- Allow reducing header dependencies? Yes/No
- Allow converting CPP macros to C functions? Yes/No
- Allow converting CPP macros to enums? Yes/No
- Allow runtime optimizations? (e.g. SIMD optimizations, adding compiler hints like expected/pure, caching memory accesses in local variables, reducing system calls etc.) Yes/No
- Allow inlining and un-inlining functions if a positive runtime effect can be demonstrated? Yes/No
- Allow code modernization to the selected C standard? (e.g. int->bool, designated initializers) Yes/No
- Allow conditional use of features in newer C standards? (e.g. C11 atomics, C23 enums) Yes/No
- Allow adding code to take advantage of certain kernel features? (e.g. THP, splice, copy_file_range, io_uring, openat2, statx)