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).
Cheers,
Fabio
On 10/9/05, Rocky Burt <[EMAIL PROTECTED]> wrote:
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
debugger.
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
debug mode).
- Rocky
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 :-)
>
> Cheers,
>
> Fabio
>
> On 9/27/05, *Aleks Totic* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] >> wrote:
>
> Fabio Zadrozny wrote:
> > Hi All,
> >
> > PyDev - Python IDE (Python Development Enviroment for Eclipse)
> version
> > 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
> initially.
>
> Cheers,
>
> Aleks
>
>
> -------------------------------------------------------
> 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
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>
--
Rocky Burt
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/pydev-code
