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
GHC doesn't optimize away profunctor type classes with profiling enabled #324
Comments
Must be inlining issue, If you're using optics or optics-consuming functions you wrote yourself they might just need to be marked with an INLINE pragma.
It's both reasons really. |
It might also be that profiling build doesn't optimize as well... |
No, I didn't check. But I straightforwardly migrated from lens - there I didn't have the problem. This means optics somehow does not inline as well.
It is good! This gives lens a more reasonable scope. But I missed |
Did you observe something like this too, that optics-related functions appear in the profile, after migrating a non-trivial lens-heavy program? Maybe it is only a profiling optimization issue, but from time to time I like to look into the profile to detect hotspots - these will be obfuscated then. |
No. Can you share the code (or construct a testcase that demonstrates this behavior)? A better check would be to look at I checked a non-trivial project and the only |
No, unfortunately I cannot share the code since it is not a small self-contained test case. But I can investigate a bit better at some point. However this has low priority for me and I am continuing to work on the lens-based branch now. I would still like to switch to optics in the future though. |
@arybczak Did you only check the resulting core output of the non-profiling or did you also check the profiling build and the profiler output? I only checked the profile, but didn't check core. |
optimized, not profiled. |
@arybczak If you have time it would be nice if you can check a profiling build. As you wrote, it is sometimes not reporting correct results since it might impede optimizations. But still - I am using the GHC profiler quite often these days and it is very helpful in pointing out the slow parts of the application. At least much more helpful than looking at perf output, due to the flattened cps compilation model. I don't want to lose that profiling ability by switching to optics. One could argue that the ability is not really lost though, since the profiling result modulo the optics functions is still somehow valid - but I don't like this perspective. In particular since this linear function took the topmost spot in my profile. If I have more time in a while, I will certainly give optics another shot and then I can be more helpful here. I would really love to use it for its more obvious/restricted api, better errors etc. But right now, I cannot unfortunately - since I cannot develop both a lens and optics version at the same time. And any kind of performance regression due to such a switch is unacceptable, since everything lens-related should just optimize away. |
I just checked profiled build and you're right, profiled build doesn't optimize away the type classes (with GHC 8.8.3), the core is littered with calls to I presume it's worth making a GHC issue for this. It might be intentional behavior to preserve call stacks though. |
It doesn't. I'm pretty sure it's intentional then. |
Here's a somewhat similar issue: https://gitlab.haskell.org/ghc/ghc/issues/12893 In particular https://gitlab.haskell.org/ghc/ghc/issues/12893#note_127879 This comment mentions how a small type class method is not inlined for some reason, preventing further optimizations from firing. Seems to be the same problem as here, where |
I would say this is not intentional or there should be at least some way to prevent this in GHC. Ideally, optimization and profiling should not interfere, but this seems to be a hard problem according to the comment by spj. Still, I think it might make sense to open a bug report or at least ask on the GHC tracker if we manage to create a small self contained example. I think the difference here is that you are explicitly requesting inlining. In that case inlining should take precedence over good profiling data. |
I submitted a GHC ticket: https://gitlab.haskell.org/ghc/ghc/issues/18374 |
The link to the GHC issue seems dead? |
Ok, that's good. If we want to get this further (apart from fixing it in GHC), I'll need you to compile your project with |
Yeah, there was a data loss during migration. The issue is at https://gitlab.haskell.org/ghc/ghc/-/issues/18374 |
Optimize away profunctor classes when profiling (#324)
Please reopen (or create a new issue) when you are able to provide core output. |
Hi,
I tried optics by switching over a project from lens. This worked very well due to the good type errors. I also think
%
is not bad and actually helps readability, since it is made clear where an optic is constructed. After finishing that I did some profiling using+RTS -p
. NowProfunctor.linear
and other optics-related functions appear prominently at the top of the profile. Is this some profiling artifact or is there some inlining issue present? Is the profunctor representation less efficient than the VL representation?Another unrelated question - Many operators like
+~
,<>~
seem to be missing from optics? Is this intentional since those can be replicated trivially or due you generally encourange a less operator-heavy style, where not every operator is replicated for lens modifications?Please let me know if you have better place to ask such questions! Thank you!
The text was updated successfully, but these errors were encountered: