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
Sync FileCacheStorage with changes from phpstan-src #498
Sync FileCacheStorage with changes from phpstan-src #498
Conversation
Thanks for the PR 👍 Could you share some basic performance comparison before/after? Just so we have an idea how "much" |
I can see a 25-35% perf improvement on my workstation, depending on load. |
Current design is based on cache in PHPStan, and I would like to keep it as close the original to make the maintenance easier. So I want to be sure it has added value, before we change the design. I've checked the numbers for CI here and in another PR and there is no perf change. Could you demonstrate it in Github Actions I could check? |
on phpstan side this class evolved already and does no longer use a smartFileSystem. This might also fix the same problem this PR is trying to fix.
Also made this observation. I guess the optimization kicks in when doing another run (which doesn‘t happen in CI because we always start from scratch); but might still be usefull for local test runs. Any idea how to best reproduce CI like performance? Any way to clear all caches or similar?
will reproduce on monday when back at the workstation |
Could you share the diff?
I would simply run the CI and compare final times before and after your change. Nothing special.
👍 |
Side idea: maybe it would make sense to have a in-memory CacheStorage for CI to get rid of slow IO |
If the numbers are better, why not :) |
Phpstan upstream version alread contains a CacheInterface and a in-memory impl in other words: using the latest upstream impl should provide everything we need. It seems phpstan even uses this classes internally exactly like proposed |
b6eaf6f
to
6823d1a
Compare
I just updated the implementation to be in line with the phpstan-src upstream FileCacheStorage. using a in-memory impl to speedup CI is a possible followup.
I compared a few builds. the numbers are highly insconsistent, so its pretty hard to tell whether the testsuite is fast/slow because of a change within a PR or whether there is some other external factor which makes the numbers change. from a logical point of view with the changed FileCacheStorage a lot less file-renaming is going on. the build is currently failing because of "style" problems:
since you wanted to be in line with phpstan-src I like to ask, which reported problems should be solved (and therefore will create differences between rector-src FileCacheStorage and phpstan-src FileCacheStorage )? which can/should be phpstan-ignored? |
@@ -23,70 +21,83 @@ public function __construct( | |||
) { |
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.
where is the $directory
configured which is used? when changing the impl we should add a v2
or similar so persisted cache information does not conflict with the new impl
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 this question still relevant or outdated? The original commit had changed
Could you check last PHPStan fails? I think it's ready then |
@TomasVotruba should be good to go |
return; | ||
} | ||
@\unlink($tmpPath); | ||
if (\DIRECTORY_SEPARATOR === '/' || !\file_exists($path)) { |
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.
have you tried in different OS ? DIRECTORY_SEPARATOR
is /
in macOS
:
➜ ~ php -a
Interactive shell
php > echo DIRECTORY_SEPARATOR;
/
php > var_dump(\DIRECTORY_SEPARATOR === '/');
bool(true)
Above code will make always throw exception.
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 implementation is taken 1:1 from phpstan.
I guess this condition is meant as a non-windows feature detect.
As this class - as is - works in phpstan for months without further bugfixes, I feel this is good enough.
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.
That possibly a dead code then, true || false
will result true, true || true
will result true, see https://3v4l.org/pKcY1
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.
I can't tell the details why phpstan has implemented it like that.
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.
Some comment would be useful so we don't use this blindly in the future
Unrelated to the PR, could you use same user as PR, eg PR from |
I am working on different workstations with different users. why is this "mix" of user/submitter a problem? In case I could only work from one of these computers my feedback/contribution loop would get longer. |
I see. Just to make easier to verify that the commit is from the PR author so it can be verified to the commit author if there is something that need to be clarified. |
return null; | ||
} | ||
return $cacheItem->getData(); | ||
})($key, $variableKey); |
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 very confusing to read. Not sure if args are on left or right.
Could you extract function to assign line and invoke it on 2nd?
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.
its the way how phpstan does this things.
all these nitpicks are great, but it goes against intially mentioned goal:
Current design is based on cache in PHPStan, and I would like to keep it as close the original to make the maintenance easier.
after we apply all 'rector rules' the diff between the phpstan impl and ours here gets bigger and bigger.
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.
Ok, you're right. Let's give it a go
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.
fwiw, I opened a upstream PR to simplify this on phpstan-src
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.
Cool! 👍
This is too much magic for me. I understand only objects and methods :D
* @param mixed $data | ||
* @return void |
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.
It seems these duplicate the PHP code
$firstDirectory = sprintf('%s/%s', $this->directory, Strings::substring($keyHash, 0, 2)); | ||
$secondDirectory = sprintf('%s/%s', $firstDirectory, Strings::substring($keyHash, 2, 2)); | ||
$firstDirectory = sprintf('%s/%s', $this->directory, substr($keyHash, 0, 2)); | ||
$secondDirectory = sprintf('%s/%s', $firstDirectory, substr($keyHash, 2, 2)); |
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.
👍
Thank you Marcus 👍 |
as can be seen in #461 (comment) the FileCacheStorage is a major bottleneck while running tests on windows - I guess the same is true on other OSes.
This PR removes unnecessary temp-file handling, because
smartFileSystem->dumpFile
is already a atomic operation which does magic temp-path file handling behind the scenes. therefore we don't need to do the same things on the rector side.