Should the line color be relative to each function or to the max global time ?

If one function calls another, it is harder to see the bad line in the callee as the caller will always take more time.
Maybe the colors can be relative to the function but with a different color than red (computed from a hash of the function name rather than random so that the color don't change between calls)

Hi,
this really looks like it should be a standard plugin to spyder.
it's an awesome functionality to have in spyder!!
Very easy to use once it's up and running.

One possible further step could be non-intrusive marking of the @Profile.
Maybe it would be possible to make a mark similar to "breakpoint" in debugging?

Here is what I had to do to get it running on my computer.
I had 2 issues (both with memory_profiler, the line_profiler worked out of the box):

First of all I run anaconda 2.3.0 py34 64-bit on win8.1
I installed line_profiler & psutil with conda. The memory_profiler was installed with pip, since conda did not have a version in the repository (also the ones found on binstar seemed to be old).

As for getting into spyder I just copied the 4 relevant files in this repository to the spyder plug-in location as per the instructions.
#1 (this library). in memoryprofilergui changed line:

from: stuff = filter(None, l.split(' '))
to: stuff = list(filter(None, l.split(' ')))
I guess this is a py2 vs py3 thing, and I took the easy way out with making a list to go back to py2 behaviour, I did not test tuple but I guess that works as well.
#2 (more spyder itself) - it did not find the right python.exe.

The line_profiler worked out of the box.
After a while I tracked it down to that for the line_profiler it started the program "kernprof",
this one I only have one version of, and that's in the anaconda installation.
The memory_profiler started the program "python", which it finds with
spyderlib.utils.programs.find_program('python').

I know that I have a pretty scattered computer with regards to python installs, but it normally works out OK.
I have 3 different base pythons installed where anaconda and a regular python are 2 of them.
There are also a couple of virtual envs from the "small python" base.

Anyways when spyderlib finds the "python" progam it finds the path 'C:\Python34\python.exe'
If I put in IPython I get 'C:\Data\Anaconda3\Scripts\ipython.exe',
in other words - although spyder is installed via anaconda, it still does not recognize this...

When I look into my os.environ['PATH'] the non-anaconda paths are before the anaconda paths in a print-out.
So I guess it finds the non-anaconda first and is satisfied with that answer.

Maybe one can use the 'SPYDER_PARENT_DIR' environ_var to select the right python install.
For myself I just put in the hard path, i.e. line no 264 executable = "c:..\Anaconda3\python.exe" to make it work on my computer.

Once more, thanks for a great integration into spyder!!

The plugin works while launched as a script from within spyder, but crashes spyder at launch when integrated as a plugin.

If run in Windows, fails with the following output:

  File "C:/Anaconda/Scripts/kernprof.exe", line 1
SyntaxError: Non-ASCII character '\x90' in file C:/Anaconda/Scripts/kernprof.exe on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

This is because kernprof.exe is run using python: Line 264 of lineprofilergui.py is

executable = '{0} {1}'.format(sys.executable, script_path)

which means executable is set to (in my case) C:\Anaconda\pythonw.exe C:\Anaconda\Scripts\kernprof.exe, whereas the correct would be only C:\Anaconda\Scripts\kernprof.exe.

Solution: Replace this line with

executable = script_path

Tested and works perfectly.

The data should be stored as a tuple to avoid having to analyse the string.

Line numbers must be padded with 0's, otherwise 100 is sorted before 99 as "10" < "99".

Hi,

When I'm profiling a function that it is inside of an imported class or library, sometimes the line_profiler GUI does not allow me to expand the function, even the output of line_profiler is OK. Other times it works fine.

This happens in both Windows and Ubuntu, so the problem should be in the code, but I don't see what could be the problem (I don't use ASCII characters for example).

I attach a figure to clarify my problem.

Thank you!

It has been meerged from #24, but the output is parsed twice, it should be simplified.

Non-ASCII characters display incorrectly.

Hi

I've got a working version of line_profiler. I follower the instructions and copied pline_profiler.py to spyderpluginsand lineprofilergui to the widget folders.
I cannot, however, see any option for line profiling once I'm in Spyder.

Code lines with a high time should have their background set in red, like in Matlab.

The line with the highest time should be in red, and the alpha decreases when the time gets lower.

This should be an option since it may render strangely if the background is not white.

It is based on line_profiler, works with the same decorator @profile and has the same kind of output : https://github.com/fabianp/memory_profiler

Use a monospace font for the code. The font should be the same as in the editor.

See https://qt-project.org/doc/qt-4.8/qtreewidgetitem.html#setFont

The link to spyder repo is outdated. Currently the repository is on github: https://github.com/spyder-ide/spyder

Line profiler fails to find the file and displays an error message when the path to the file being profiled contains a blank space...i.e., "C:\Python\test prog\test.py" will fail. If I move test.py to the path: "C:\Python\test\test.py" it works fine.

Seems like it should be a simple fix due to incorrect handling/joining of path strings for Windows systems?

What is the use of the -b flag for kernprof.py ? profile seems to be added to the namespace even without it.

There's a blank line before the @profile decorator in the results, but it seems that it is not present on all systems.

Is this even possible ?

the kernprof program may be installed for another python executable. The right one should be used.

Is it really necessary to group by file before grouping by function ? The original line_profiler groups by function only.
The @profile decorator is rather function-oriented. I thought there was a way to enable/disable the profiler globally but I can't find it any more. In this case grouping by files may be better.

If grouping by function, a solution may be to prepend the function with the file name and line number, the sorting by function would also sort by name. The problem being that the path can be very long.

At first launch, if the preference window is not opened first, the following exception is raised:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/spyderplugins/p_lineprofiler.py", line 134, in run_lineprofiler
    self.analyze(self.main.editor.get_current_filename())
  File "/usr/lib/python2.7/dist-packages/spyderplugins/p_lineprofiler.py", line 151, in analyze
    use_colors = self.get_option('use_colors')
  File "/usr/lib/python2.7/dist-packages/spyderlib/plugins/__init__.py", line 239, in get_option
    return CONF.get(self.CONF_SECTION, option, default)
  File "/usr/lib/python2.7/dist-packages/spyderlib/userconfig.py", line 307, in get
    raise cp.NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'use_colors' in section: 'lineprofiler'

It seems that the option is not created when the plugin is loaded.

In the output, if only a single function is profiled, I think it would be nice if it was expanded by default.

Hi @Nodd, pretty cool plugin :)

What do you say if we turn this into a python package and start tryouts for a plugin manager in Spyder?

Have you ever use pypi packaging?

Cheers

After running line_profiler, warn that @Profile decorators are needed by line_profiler.