-
Couldn't load subscription status.
- Fork 11.6k
refactor: Some minor performance & readability enhancements #53596
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
Conversation
|
The refactored version is harder to read than the previous version! (For me) |
|
In contrast, I like it and can follow it better. I think it helps keep a clean code base so +1! |
|
Marking as draft since tests are failing. |
f17d980 to
7377c4b
Compare
|
@crynobone all tests are passing now, only one minor change to a single test (mocking |
| if (in_array(InteractsWithQueue::class, $uses) && | ||
| in_array(Queueable::class, $uses) && | ||
| ! $command->job) { | ||
| if (isset($uses[InteractsWithQueue::class], $uses[Queueable::class]) && ! $command->job) { |
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.
This is an incorrect refactor. isset looks at the keys. in_array looks at the values.
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.
Isn't class_uses_recursive() outputting the exact same key as value?
[
SomeConcern::class => SomeConcern::class,
]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.
@GrahamCampbell as @ralphjsmit points out, the result of class_uses_recursive() is a key-value pair with the trait name for both, therefore you can use isset() to check for the usage of a trait (O(1)) rather than traverse the array till you find the value using in_array(). (O(n))
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.
This should be fine and we use isset() as well for
framework/src/Illuminate/Foundation/Testing/Concerns/InteractsWithTestCaseLifecycle.php
Lines 196 to 220 in eb625fa
| $uses = array_flip(class_uses_recursive(static::class)); | |
| if (isset($uses[RefreshDatabase::class])) { | |
| $this->refreshDatabase(); | |
| } | |
| if (isset($uses[DatabaseMigrations::class])) { | |
| $this->runDatabaseMigrations(); | |
| } | |
| if (isset($uses[DatabaseTruncation::class])) { | |
| $this->truncateDatabaseTables(); | |
| } | |
| if (isset($uses[DatabaseTransactions::class])) { | |
| $this->beginDatabaseTransaction(); | |
| } | |
| if (isset($uses[WithoutMiddleware::class])) { | |
| $this->disableMiddlewareForAllTests(); | |
| } | |
| if (isset($uses[WithFaker::class])) { | |
| $this->setUpFaker(); | |
| } |
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.
@crynobone the array_flip() in that example should probably be removed too… (unrelated to this PR)
|
|
||
| if (isset($command->delay)) { | ||
| return $queue->later($command->delay, $command); | ||
| return $queue->later($command->delay, $command, queue: $command->queue ?? null); |
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.
Is it not possible to maintain using laterOn and pushOn for 11.x and change it for 12.x?
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.
@crynobone The methods aren't going anywhere, it's just unclear if there is any implementation that does anything except wrap the other functions.
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.
Yeah, just thinking if existing application using Bus::spy() and Bus::shouldHaveReceived('laterOn') and with these changes, it starts to cause failing tests.
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.
Happy to back that part out, although those feel like brittle tests I don't think it's good to break things for the sake of breaking things.
During my latest Inside Laravel livestream I noticed some minor inefficiencies in the Dispatcher code. These most likely are just older code that never got updated.
This includes 3 changes:
isset($uses[InteractsWithQueue::class], $uses[Queueable::class])instead of a two expensivein_array()calls, this takes two O(n) operations to just O(1).call_user_func()call with a dynamic method call, using($this->queueResolver)to dererefence the property before calling the closure within.pushCommandToQueue()implementation which previously checked if queue and/or delay were set and then callingpushOn()orlaterOn()when with named params we can easily just callpush()andlater()— the use ofqueue: $command->queue ?? nullrather than justqueue: $command->queueis for readability. This one is the only one I'm concerned about, it's possible that an implementation of theQueueinterface/child of theQueueabstract class has different behavior than just wrappingpush()andlater()— but as those must support thequeueparam I don't see any issue with it.