search

julia-actions / julia-invalidations

Uses SnoopCompile to evaluate number of invalidations caused by `using Package` or a provided script
29 stars 9 forks source link

Separation of the environment between recording phase and analyzing phase #17

Open kimikage opened 7 months ago

kimikage commented 7 months ago

Because SnoopCompile depends on many packages, this action cannot be used to inspect basic packages on which SnoopCompile itself (indirectly) depends. As a specific example, the problem is happening with FixedPointNumbers (https://github.com/JuliaMath/FixedPointNumbers.jl/pull/283#issuecomment-2053766644).

In other words, most packages related to graphics cannot be checked with the latest "development" branches. This specific problem may be mitigated by mimicking the FixedPointNumbers version from "0.9.0-dev" to "0.8" (Edit: cf. https://github.com/JuliaMath/FixedPointNumbers.jl/pull/287), but it is not a fundamental solution.

I do not understand how portable or exchangeable the invalidation trees are in its current state, but they should be portable.

IanButterworth commented 7 months ago

We could move the installation of SnoopCompile to after the invalidations have been collected by SnoopCompileCore, and install it into a temp env.

There's a chance that loaded versions of packages would be incompatible though, but it should work around the issue you raise.

kimikage commented 7 months ago

This is more of a SnoopCompile issue than this action, but does the collected MethodInstances really have to be "live" in the world of analysis phase? Of course, I can foresee a great deal of complication there, though.

kimikage commented 7 months ago

To return to the topic, I believe that it would be sufficient to provide the ability to separate the phases with respect to this action. It would be the responsibility of the caller of this action to make sure it works well.

Edit: Of course, I believe that the analysis phase can and should be separated from the visualization phase. In fact, SnoopCompile does not depend on PrettyTables.

kimikage commented 7 months ago

I may have misunderstood the purpose of this action in the first place. Is this action by any chance to see what invalidation occurs for a "standard" benchmark environment with Colors.jl etc.? If so, it is important to note that reducing dependencies may deprive the users of the opportunity to become aware of their invalidations. In any case, it would be nice if the default behavior could be similar to the current.

timholy commented 4 months ago

This seems generically resolvable by always doing the data collection with just SnoopCompileCore. Cases like FixedPointNumbers are what motivated the split in the first place.