Hi Rocky,

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 <rocky@serverzen.com> 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* <a@totic.org <mailto:a@totic.org >> 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
>     Pydev-code@lists.sourceforge.net
>     <mailto:Pydev-code@lists.sourceforge.net>
>     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
Pydev-code@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pydev-code