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

[SourceForge.net]

Bugs item #629985, was opened at 2002-10-28 12:28
Message generated for change (Comment added) made by kbk
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: Kurt B. Kaiser (kbk)
Date: 2003-12-02 13:07

Message:
Logged In: YES 
user_id=149084

Quite right! The notes were incorrect and pernicious pasting
took care of the rest.  It's select.select() and wait=0.0.

ModifiedInterpreter.poll_subprocess() wasn't setting the wait
parameter so it was silently defaulting to 0.0 which caused
pollresponse() to return immediately if there was no data.
It then rescheduled itself. This was causing a 100% slowdown
relative to just waiting for 50 ms in rpc's SocketIO.pollpacket().
There was also a stutter at the beginning of the output which
made it look even worse.  I never did figure out what was
causing the stutter but it went away when I made the change.
(This comment relates to the synchronous comm link.)

The async link was a different case, it was blocking instead
of polling in pollpacket().

At this point IDLE1.0 is 70% slower than IDLE0.8 when
outputting sequences of " 1".  This is some kind of worst
case.  It's still pretty responsive, and this particular problem
isn't an issue in most cases, the limiting factor is the Tk
text scrolling.  I'll bum it some more some day.

Thanks for the correction!

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

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 14: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