fasten your seat belt - #phpstan 2.3.x will be a another massive step forward 🥳
we are not yet ready with it though 🤡
Remote
markus staab
@markusstaab@phpc.social
mastodon 4.7.3software development with passion - open-source lover, creator of staabm/phpstan-dba, excessive freetime @phpstan@phpc.social, @rectorphp and @phpunit@phpc.social contributor
279 Followers
36 Following
36 Posts
Joined November 08, 2022
GitHub:
Twitter:
see you on #phpdd next week in dresden?
Replying to
@OndrejMirtes@phpc.social I agree that people which are disciplined and motivated will create more good code with LLMs than without.
My personal experience on the other hand tells me that only 20-30% of the devs are disciplined and motivated. And the biggest part of the devs will produce more low quality code even faster
Last week I had an idea on how we can improve efficency when #phpstan needs to work with big unions of constant types (e.g. enum with lots of caes).
this had a nice impact on some example of our benchmark suite
Anyone out there with a open source codebase, running #phpstan in CI takes more than 5 minutes?
I would love looking into what makes it slow for you
Send me a link to your CI logs
RT
Achievement unlocked: crossed the 1000 commits line in @phpstan@phpc.social core
@OndrejMirtes@phpc.social had another great idea to speedup #phpstan analysis
Implementing it was easier than expected :-)
my non-scientific benchmark suggests running #PHPStan on #wordpress core, will be a lot faster starting with the next release
It was a pleasure to work with @misterdeviling@bird.makeup thru a lot of old #PHPStan bugs. Yesterdays release contains a massive package of fixes.
while we concentrated on the maintenance parts, @OndrejMirtes@phpc.social could concentrate his efforts on improving DX with better docs and other nice additions.
@OndrejMirtes@phpc.social handed me over a list of #php-src commits to verify and contribute to the php runtime.
So I started opening pull requests on the php project to improve performance of #phpstan.
Lets see how it goes - wish me luck :-)
yesterdays #phpstan 2.1.43 release fixes 37 issues.
this means since 2.1.40 (released ~4 weeks ago) we fixed ~195 issues.
fingers crossed we can keep the pace and reach our goal of pushing open issues to < 1000 in the upcoming months.
dumdidum.. 🚀
Recently I learned that the order in which you pass options to a CLI command can have a huge perf impact on the runtime (even if it leads the same result)
I recently learned that git bisect has a "run" subcommand, which allows you to automate the bisect process.
in a blog post I am describing how you can find a regression commit in phpstan-src.
the same approach works for any git based project.
I love solving puzzles..
today I found out that a #phpstan container cache invalidates when you resize your bash/shell window. also when jumping between directories using `cd`.
not intentional of course. lets see what we can do about that.
In case your daily #phpstan run takes minutes instead of seconds you likely don’t utilize the result cache.
Find solutions at https://staabm.github.io/2023/10/21/phpstan-result-cache-gotchas.html
Replying to
@edorian@phpc.social we do it on thursdays ;-).
such workflows will be even more helpful, after we are able to make the baseline allow to only remove errors.
atm your weekly PR could also hide new errors in the baseline
https://github.com/phpstan/phpstan/issues/9695
Replying to
@jrf_nl@phpc.social fixed in https://github.com/phpstan/phpstan-src/pull/4924
The cache key depends on $ENV and bash adds variables COLUMNS, LINES or OLDPWD based on user interactions
Starting with #phpstan 2.1.39 in case we know constants are deprecated only in certain php versions, we no longer error about them, when used in a `if (PHP_VERSION_ID < 80400) {`-like condition.
see E_STRICT before PHP 8.4:
https://phpstan.org/r/0dc9fe34-0c60-4254-9174-f37e910cb4cf
TIL: your github action might fail because of a overlong command line, which gets cut without further notice.
Not sure its a #php or #windows or #githubactions effect.
1:1 the same command works on a ubuntu based github action without error
Replying to
@Romm@mastodon.social we are running all previous "slow examples" in the test-suite and try to monitor that we don't regress on performance.
I am planning to make the perf numbers visible, maybe similar to https://ajenbo.github.io/phpantom_lsp/dev/bench/
Replying to
@edorian@phpc.social I agree. See my comment in the fixing PR
while I think this is just a workaround for a more general problem - I see no way atm to find out which ENV vars are relevant for us and which are not
The fact that nobody reported a problem and I found this bug just by incident, tells me that it seems not „broken enough“ to spent time on it though.
It seems we don’t invalidate waaay to often and spam temp-cache files and we don‘t cache too aggressively and produce bugs.
We have a few really cool perf experiments running atm to get #phpstan even faster.. some of them look really promising. 🫰
Replying to
@ocramius@mastodon.social at phpstan we use https://toggl.com/
we have a pretty simple use-case though
Since April 2026 we fixed ~280 issues on #phpstan.
We implemented lots of new features and improvements along the way and made it even faster at the same time.
be prepared for the next release which will do another big leap in #performance 🚀
#phpstan 2.2.3+ is able to detect package updates based on composer.lock.
utilizing the pre-existing dependency graph, we need to re-analyze only affected files. Previously we had todo a full project analysis.
contributed by @sander_scode
Replying to on mastodon.social
@zimzat@mastodon.social not sure what you mean. I have written plenty of extensions without such a problem.
Might be specific to a certain extension. If reproducible please file a issue
contributed to #phpstan by @zonuexe@phpc.social: PHPStan will have a better idea about purity of callables taking a callback argument.
for example will array_map($pureCb, $arr) be considered pure:
- less false positives
- better dead code detection
In case you think #phpstan is running too slow, have a look at the result of running phpstan analyze command with -vv and check whether it utilizes the result cache
When the result cache is warm, it should be wicked fast
in CI you likely need to persist the cache manually
see https://phpstan.org/user-guide/result-cache#setup-in-continuous-integration
Replying to
@Girgias@phpc.social a finite type set, specialized for looking up constant types in a union of constant types
https://github.com/phpstan/phpstan-src/pull/6116
Replying to
@toflar@phpc.social @naderman@phpc.social the code shadowed in c++ can be found here https://github.com/phpstan/phpstan-src/tree/2.2.x/turbo-ext