[Filesystem] Cache more calls in Path #58890
Comments
|
Thank you for this issue. |
|
No unfortunately it has not been resolved. I would be happy to work on a PR but I want to know the path forward so I guess whoever would have merge-power for a PR against the filesystem component would need to give feedback on may strategic questions (what can be cached and how do we reset?). |
|
You can start by creating a performance benchmark, using phpbench. Then you identify the slow parts and work on optimization and caching, in this order. We truly appreciate having the benchmark results before and after the change, as part of the pull request description.
The buffer system prevent memory leaks as there is limit in the number of items. |
Yes, of course. The question was more if we should keep that because we basically have this nowhere else in Symfony. Maybe I'll just do a proposal then. |
|
I tried using phpbench and blackfire but I was unable to find a way to improve this. I mean there is a benefit when caching for sure but it's so marginal that building a proper static |
Description
In our project, we use
Path::makeRelative()quite extensively. In 90% of all cases$basePathis identical. But still, Symfony callsself::split($basePath)on this on every single call wasting lots of resources.We already cache the results of
canonicalize()in$bufferwith some$bufferSize"magic". Before creating a PR, I wanted to ask which way we should go here. There's actually a lot that could be cached in this utility class. Who defines which methods qualify for a static buffer?And is that buffer handling even the correct approach? Should't we have a
static reset()or so? Should the existingfilesystemservice callPath::reset()then?Wdyt?
Example
No response
The text was updated successfully, but these errors were encountered: