Skip to content
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

Difficult to quickly see largest allocations #145

Closed
fonsp opened this issue Mar 12, 2022 · 2 comments
Closed

Difficult to quickly see largest allocations #145

fonsp opened this issue Mar 12, 2022 · 2 comments

Comments

@fonsp
Copy link

fonsp commented Mar 12, 2022

In a table like this one, it is difficult to quickly see which tests had a large number of allocations, you have too read carefully to find GB instead of MB:

 ─────────────────────────────────────────────────────────────────────
                                           Time          Allocations
                                     ───────────────   ───────────────
           Total measured:                 740s            14.0GiB

 Section                     ncalls     time    %tot     alloc    %tot
 ─────────────────────────────────────────────────────────────────────
 import Pluto                     1    459ms    0.1%   66.0MiB    0.5%
 compiletimes.jl                  1    24.7s    3.4%   2.10GiB   15.3%
   SessionActions.open            1    12.5s    1.7%   1.14GiB    8.3%
   SessionActions.shutdown        1    563ms    0.1%   71.5MiB    0.5%
 Events.jl                        1    4.58s    0.6%    405MiB    2.9%
 WorkspaceManager.jl              1    93.3s   12.7%   1.01GiB    7.4%
 packages/Basic.jl                1     148s   20.1%    878MiB    6.2%
 Bonds.jl                         1    27.0s    3.7%    284MiB    2.0%
 RichOutput.jl                    1    45.1s    6.1%   1.31GiB    9.5%
 React.jl                         1     116s   15.8%   2.91GiB   21.2%
 Dynamic.jl                       1    31.5s    4.3%    799MiB    5.7%
 MacroAnalysis.jl                 1    98.9s   13.4%    825MiB    5.9%
 Logging.jl                       1    15.1s    2.0%   52.8MiB    0.4%
 webserver.jl                     1    20.6s    2.8%   1.52GiB   11.1%
 Notebook.jl                      1    87.5s   11.9%    568MiB    4.0%
 Configuration.jl                 1    8.27s    1.1%    402MiB    2.9%
 ReloadFromFile.jl                1    4.92s    0.7%    100MiB    0.7%
 packages/PkgCompat.jl            1    398ms    0.1%   33.1MiB    0.2%
 ExpressionExplorer.jl            1    5.28s    0.7%    317MiB    2.3%
 MethodSignatures.jl              1    132ms    0.0%   15.7MiB    0.1%
 MoreAnalysis.jl                  1    925ms    0.1%   79.9MiB    0.6%
 Analysis.jl                      1   94.6ms    0.0%   4.12MiB    0.0%
 webserver_utils.jl               1    818ms    0.1%   43.1MiB    0.3%
 data structures.jl               1    713ms    0.1%   68.3MiB    0.5%
 DependencyCache.jl               1    355ms    0.0%   27.4MiB    0.2%
 Throttled.jl                     1    841ms    0.1%   2.14MiB    0.0%
 cell_disabling.jl                1    536ms    0.1%   26.9MiB    0.2%
 ───────────────────────────────────────────────────────────────────── 

Ideas:

  • Use colors/bold to highlight the highest values in a column. Or to highlight >1GB values.
  • Show everything in integer MB. 1.23GB would show as 1234MB, clearly standing out over 123MB and 12MB.
  • Show sizes >1GB with 4 significant digits, <GB with 3 (as we currently do). That way, all >1GB numbers will stand out. But 123MB and 1.23MB will still look very similar.
@KristofferC
Copy link
Owner

KristofferC commented Mar 12, 2022

You can use sortby=:allocations to the printing so big allocations will be at the top. You also see the %tot in the right column which makes it pretty clear, no?

@fonsp
Copy link
Author

fonsp commented Mar 12, 2022

😅 Just realised what the %tot column does, that's what I needed, thanks!

@fonsp fonsp closed this as completed Mar 12, 2022
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

No branches or pull requests

2 participants