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
