Profiling user code

[ViralBShah]

Our profiler currently gives a bunch of output that goes deep into the base library. Often, users are just profiling their own code, and just want to look at which of their lines are consuming time. It is daunting to see the profiling information for all the internals.

I believe it should be easy enough for us to just provide profiling info on user code, avoid printing the lines that are in Base or other modules, and have an optional argument to include that information.

Ideally, I would love to see profiling information for my own code, and my own modules, and not Pkg installed modules and Base. I don't know if we can easily implement that, unless we scan METADATA.

[timholy]

I agree that massive text output is an impediment, but doesn't having a graphical output (ProfileView) eliminate this concern?

[StefanKarpinski]

Getting ProfileView to work on Windows is a non-trivial (possibly unsolved?) problem. It would be nice to make the bare-bones thing that everyone can guaranteed use as usable as possible.

[timholy]

Didn't realize that it doesn't work on Windows. Why doesn't it? It basically needs backtraces (which used to be bad, but I think @vtjnash improved them?) and Tk.

[timholy]

(or if you're using Juno, doesn't even need Tk)

[StefanKarpinski]

I've never gotten Tk working on Windows, although it may well be possible.

[timholy]

At one point long ago (EDIT: probably pre-0.3) it worked. I haven't used julia with Windows since then, however.

I plan to update ProfileView to Gtk someyear, perhaps that would help.

[timholy]

Anyway, with regards to text output: presumably it's just a question of parsing the path. Try this and see if it looks promising:

@profile somecode
bt, lidict = Profile.retrieve()
for (k,v) in lidict
    println(v)
end

One of the fields in lidict corresponds to the file: if you can use the path to reliably distinguish Base, then this is achievable.

[tkelman]

ProfileView works on Windows...

Last time I checked Tk fails one of its tests due to some silly path-separator escaping, but otherwise seems fine.

[StefanKarpinski]

Ok, that's good. Nevertheless, simplified profile printing wouldn't hurt; marking as up for grabs.

[timholy]

I don't mind doing it, but we really need to migrate to a graphical world :-).

ATM the task switch away from #10525 (comment) is too expensive.

[StefanKarpinski]

Don't let this distract, @timholy – I think this is a good up for grabs issue.

[MikeInnes]

For what it's worth, I just finished making the Juno profiler (complete with fancy file views etc.) work as a standalone package, which might be useful if ProfileView.jl has platform issues. It'll be easy enough to fade out lines from base/packages a little, although I think that's less necessary when you can see the results inline in the code anyway.

I actually don't think it's such a bad idea to expose users to Base a little – the whole idea is that there's no difference between their code and ours, and it's good for gradually onboarding developers ;)

To anyone looking to implement this, it should be fairly easy to do. Files from base are stored as relative paths (e.g. abstractarray.jl or sometimes ./abstractarray.jl on Linux) and everything else is absolute. Files from packages will of course be prefixed by Pkg.dir(). So it's just a case of pruning those branches from the tree.

[ViralBShah]

Oh yeah, exposing Base is completely fine - but often at times you write a 20 line algorithm, and it becomes difficult to see where the code is spending time. I would love a default that hides, but have a button that shows all the details.

Can you prepare Juno binaries with the integrated profiler?

[MikeInnes]

Juno does come with an integrated profiler already, if that's what you mean? The new one is essentially the same idea but can be added with Pkg.add() and used from the REPL, without installing Juno.