[Idle-dev] [ idlefork-Bugs-629985 ] Slow output

SourceForge.net noreply at sourceforge.net
Sun Nov 30 16:51:38 EST 2003


Bugs item #629985, was opened at 2002-10-28 12:28
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=629985&group_id=9579

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 4
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Slow output

Initial Comment:
When a program writes many small amounts of text to
sys.stdout, the RPC package really seems to slow things
down. Perhaps the RPC mechanism can be extended with a
special case for "no-return" method calls, where the
client doesn't wait for a response and the server
doesn't send one. (This should only be done for
functions that aren't expected to return a value or
raise an exception, of course.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-11-30 16:51

Message:
Logged In: YES 
user_id=6380

I don't see any signal calls in the rpc code. Maybe you
meant select.select? Also, wait=None should cause select()
to wait forever (until I/O is possible), not return
immediately. But yes, it does look like it was being invoked
with wait=None from asyncreturn(), and that was switched to
0.05 on May 8th in rpc.py rev 1.23. (The CVS comment also
mistakenly talks about signal instead of select. :-)

In any case, thanks for the changes, the response time
really *is* much better now.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-11-30 15:17

Message:
Logged In: YES 
user_id=149084

Retrospective: This was greatly improved in May 2003 by tuning
the signal() parameters.  From my notes at the time, for
future reference:

"Problem was being caused by rpc.SocketIO.ioready() using
a wait=None.  This causes signal.signal to return immediately forcing
re-schedule of PyShell.ModifiedInterpreter.poll_subprocess(), I think.
Setting these wait()s to 50 ms helped a lot - got about 100%
improvement from worst case."


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-13 15:18

Message:
Logged In: YES 
user_id=6380

I think this has been hashed to death; there are some
mysteries, but it's no big deal any more.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=629985&group_id=9579



More information about the IDLE-dev mailing list