well, you can take a look at my blog (http://pydev.blogspot.com/2005/10/high-speed-debugger.html) for some comments on the debugger... please, test it after the new release to see if it suits your needs...
And also, yes, I have considered integrating rpdb2, but its license is not compatible to the pydev license (it is gpl, and pydev is cpl... I would not like to change its license just to integrate another debugger, especially considering that the debugger will already be much faster in the next release).
I've been trying to run (without modifying any pydev) Zope2.8 in the
debugger. The slowness of the debugger renders this a useless task (I
waited 15min for Zope to stop initializing and then gave up... although
I did see that it was making some progress it was just too slow).
So separately from this I decided to run my zope unit tests through the
debugger (doesn't actually have to load up zope and the tons of
packages) but even that was horribly, painfully slow.
Bottom-line right now is that if I really really need to, I'll launch
the debugger to run a unit test... otherwise I steer far away from the
Here's a question, have any of you considered integrating rpdb2
(http://www.digitalpeers.com/pythondebugger/) with PyDev? From my
experience with using it locally it was very very fast (didn't notice
much of a speed difference between running in debug mode versus not in
Fabio Zadrozny wrote:
> Hi Aleks, nice to hear from you :-)
> Actually, after checking it more, the xml is not actually the slowest
> part as it seems at first... mainly because it is executed only on
> breakpoints... The bad part is the way the global tracing function is
> set, analyzing contexts that it should not even know about (that's the
> trace_dispatch function)... it almost always return itself to debug on
> other contexts, when it should return almost always 'None' and just
> return itself on valid contexts... (you can actually 'feel' that when
> you put a large program to run... it could take a lot of time just to
> get at the first breakpoint.)
> I think that actually making an asynchronous debbuging, so that the
> communication would be on a non profiled thread and making the breaks
> just where needed would do the trick, but I'm unsure of how should this
> work if the user sets some breakpoint after we returned None in the
> trace_dispatch... Also, that would probably require heavy changes in the
> structure being used, so, I want to be sure that this is the right way
> to do it, before jumping at it... jython is also a concern, since I'm
> not sure if it works exactly as python on that...
> The xml part could also be improved as you said, but I don't think it is
> the slowest part right now :-)
> On 9/27/05, *Aleks Totic* <firstname.lastname@example.org <mailto:email@example.com >> wrote:
> Fabio Zadrozny wrote:
> > Hi All,
> > PyDev - Python IDE (Python Development Enviroment for Eclipse)
> > 0.9.8.2 <http://0.9.8.2> has been released.
> > * .pyc is removed when the corresponding .py file is removed.
> > * Debugger has been changed so that it becomes faster (still
> not as
> > fast as I would like, but still... faster) -- looking for people with
> > expertise on this to help me, as I'm kind of lost on which should
> be the
> > 'recommended' way to speed it more.
> Not sure what are you doing with the debugger right now. The
> major cause of slowness used to be transfer of variables. This
> was particularly painful when a file imported many packages.
> Since everything in Python is global, we'd transfer 1000s of
> variables encoded as XML.
> This can be speeded up a lot by loading only "local" variables.
> Once the breakpoint is hit, use the editor model to figure out
> what the local variables are, and transfer only those values
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> Pydev-code mailing list
ServerZen Software -- http://www.serverzen.com
ServerZen Hosting -- http://www.serverzenhosting.net
News About The Server -- http://serverzen.net
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Pydev-code mailing list