Monday, May 30, 2011

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/

Wednesday, May 18, 2011

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...

Thursday, May 05, 2011

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 :)