Skip to content

Conversation

@timholy
Copy link
Member

@timholy timholy commented Nov 25, 2020

This analysis tool is useful to detect methods that get a crazy number
of specializations. These are candidates for refactoring into smaller,
more independent chunks or nospecialize annotations.

@timholy
Copy link
Member Author

timholy commented Nov 25, 2020

Test failure fixed by #153 (reflected in the "pull request" passes even though the initial "push" failed).

@timholy timholy closed this Nov 25, 2020
@timholy timholy reopened this Nov 25, 2020
@timholy timholy requested a review from NHDaly November 27, 2020 21:34
Copy link
Collaborator

@NHDaly NHDaly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome Tim! :) Thanks, this is nice.

end
end
return sort([t=>m for (m, t) in tmp if t >= tmin_secs]; by=first)
end
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is perfect! 👌!

I should've realized we needed this function a while ago -- I've been just reusing this line from my julia REPL history 😬 !:

julia> ms = let ms = DefaultDict{Any,Float64}(0)
           for (t,mi_info) in times
               ms[mi_info.mi.def] += t
           end
           ms
       end;

julia> methods_sorted = sort([v=>k for (k,v) in ms], by=first)

It looks exactly identical to what you've done here 👍 👌

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One slight difference is that you allow m to be a Module. If we include modules then we might need to reconsider the name.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh good point. I hadn't realized I think that m could be a Module...

I'm not sure what's best. I guess if one of the MethodInstances where m is a Module was accounting for most of the time, I'd be sad if we missed it because we were filtering those out! So maybe we should include them too?

I dunno if we really need to change the name, since it's usually a method? Or maybe we could call it accumulate_by_definition(), to be more inclusive?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, now the logic is:

  • if mi.def is a Method, aggegation makes sense and use the Method as the key of the dict
  • if mi.def is a module, it's perfectly possible for there to be multiple thunks from the same module. Hence, we just preserve mi.

Copy link
Member Author

@timholy timholy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like we're mostly in accord here, just a couple of details to hash out.

end
end
return sort([t=>m for (m, t) in tmp if t >= tmin_secs]; by=first)
end
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One slight difference is that you allow m to be a Module. If we include modules then we might need to reconsider the name.

Copy link
Collaborator

@NHDaly NHDaly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I'll leave you to address the remaining comments as you see fit :) Thanks @timholy!

end
end
return sort([t=>m for (m, t) in tmp if t >= tmin_secs]; by=first)
end
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh good point. I hadn't realized I think that m could be a Module...

I'm not sure what's best. I guess if one of the MethodInstances where m is a Module was accounting for most of the time, I'd be sad if we missed it because we were filtering those out! So maybe we should include them too?

I dunno if we really need to change the name, since it's usually a method? Or maybe we could call it accumulate_by_definition(), to be more inclusive?

end

"""
accumulate_by_method(pairs; tmin_secs = 0.0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I'm a little unhappy that the docstrings (really, Example sections) I've added are so long. I think I'll refactor that to include an example in @snoopi_deep that covers all the use cases and then refer to it (without repeating it) from each individual function. But it will be easiest to merge them all and then fix the docstrings, just so they can be harmonized. So don't worry too much about the Example section for now.

timholy and others added 3 commits November 29, 2020 11:34
This analysis tool is useful to detect methods that get a crazy number
of specializations. These are candidates for refactoring into smaller,
more independent chunks or nospecialize annotations.
@timholy timholy force-pushed the teh/accumulate_by_method branch from 2f88978 to 105ae95 Compare November 29, 2020 17:35
@timholy
Copy link
Member Author

timholy commented Nov 29, 2020

Now this is called accumulate_by_source, and I'll add a second method in #159. That will reduce the number of exports by 1, whew.

@timholy timholy merged commit 8e17e8a into master Nov 29, 2020
@timholy timholy deleted the teh/accumulate_by_method branch November 29, 2020 18:16
This was referenced Nov 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants