-
-
Notifications
You must be signed in to change notification settings - Fork 687
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
feature request: function inliner #3564
Comments
The code snippets are long and hard to read. Could update it with -a
+b |
This better? public function bar(int $number) {
- $value = max($number, self::DEFAULT_VALUE);
- $this->quux($value);
+// inline start of function max()
+ if ($number > self::DEFAULT_VALUE) {
+ $__maxTmp = $number;
+ goto __maxEnd;
+ }
+
+ $__maxTmp = self::DEFAULT_VALUE;
+ __maxEnd:
+
+// inline end of function max()
+
+ $this->quux($__maxTmp);
} Basically, just inlining the function. |
Better. Could you make it like 5 lines max? I still don't get it. The less code, the better. Also post it into the first issues description, not to reply. I'll remove those clutter comments. |
Closing as missing test case. The best way to create such a rule is to use Rector recipe: https://github.com/rectorphp/rector/blob/master/docs/rector_recipe.md If you're able to add a failng test case that way, I'll help you to create it |
rectorphp/rector-src@2380f6a Revert [Tests] Remove RunTestsInSeparateProcesses in rules-tests (#3564)
Feature Request
One thing I've been thinking about is code optimisation, particularly as the JIT for PHP 8 is not actually delivering performance increases for things that are not equivalent to fibonacci/mandelbrot generators.
This is due to the internals of PHP actually being quite fast, and so there are little areas for improvement internally.
However, there is a huge untapped reserve of optimisation around reducing/removing the function call overhead.
This is particularly relevant for trivial functions that do trivial calculations. For the example below, even just the type checking done for the parameter might be equivalent for the amount of work done for the function.
And that's even before the whole amount of work done for creating a stack frame.
Code example
So this code:
Can be refactored by:
And it will be faster. Obviously, single function calls are not where the gains are, but for things that are called thousands of times in loops...
Scope of feature request
If that was available, I would use it to experiment to see exactly how much performance could be gained for any libraries that have a relatively high number of small functions.
The text was updated successfully, but these errors were encountered: