PyDev 2.1.0 released

PyDev 2.1.0 has just been released, with a few noteworthy changes:

The first change that's noteworthy is that only files opened in an editor will be code-analyzed... Until now, any file changed in the workspace would be analyzed for coding errors, which is a process that is usually fast, but there are 2 problems there:

1. if lots of files changed at once, it could still be costly to make that analysis (and on really big files, that could be a problem too)

2. there's no dependency analysis to know if a file should be re-analyzed when a given file changes, so, the actual state of warnings/errors could be misleading

Still, as sometimes it's useful to do the analysis of many files at once, it's now possible to right-click a folder in the PyDev package explorer and ask for a full code-analysis to be done (note that the re-indexing of internal information still must be done for any file changed, but this process is pretty fast).

Another nice feature added is a code-completion to override methods, so, after typing "def ", a code-completion may be requested to override a given method.

And for TDD lovers, there's now an option to relaunch the last launch in the PyUnit view whenever a file changes :)

The full details on the release may be seen at: http://pydev.org/

PyDev: Paying down technical debt...

Yeap, pay time :)

The next release is taking a bit more than usual because I'm taking time to pay some of the technical debt that PyDev accumulated over the years...

Not that this will also reflect in a bunch of things that will be noticed externally (e.g.: faster build times) and there are some features added too, such as an override methods code-completion...

The current nightly is already stable (although there are some more changes that are still planned), so, anyone curious is welcome to grab the latest nightly and take it for a spin...

Profiling slow downs on Eclipse

Java has this very nice utility that ships with the JDK called Java VisualVM which can provide many insights about what may be happening inside a java vm.

The steps for verifying are:

1. Have the actual java JDK installed (not only the jre) -- preferably the latest java 6.

2. Start Eclipse with -Dcom.sun.management.jmxremote vmarg (edit the eclipse.ini file and add a line -Dcom.sun.management.jmxremote after the line -vmargs -- at least for Eclipse 3.6.x -- and restart it)

3. Go on with your life until you get to something that's slow.

4. When you get up to that point, start up the Java VisualVM: it's an executable usually located at: JAVA_HOME\bin\jvisualvm.exe

5. Double click the java process running Eclipse (may appear as <Unknown Application>)

6. Go to the 'monitor' tab and check if the Heap/PermGen is too close to the max size (if it is, probably the -Xmx argument must be raised in eclipse.ini -- if you feel it shouldn't be taking up so much memory -- i.e.: there's a memory leak, click the 'heap dump', which may be a big file, zip it, upload it somewhere and point to it in a bug report).

7. If the memory seems fine, the next step is seeing up the threads running and creating a thread dump and right after it, go to the sampler, click on cpu to get sample data and add that data to a bug report (and attach both the thread dump and the sampler info to a bug report).

And hopefully, that's enough information to know what may be wrong :)