This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Thorben
Recipients Thorben, giampaolo.rodola, pitrou, thorben
Date 2008-09-11.16:13:09
SpamBayes Score 1.5546324e-05
Marked as misclassified No
Message-id <3b5d765a0809110913k46e97dcfh5d68f0d4b03ea0e1@mail.gmail.com>
In-reply-to <17573_1221149000_m8BG3Hwu019782_1221148996.4.0.214286279668.issue3766@psf.upfronthosting.co.za>
Content
The problem exists even if the server part is replaced by a server
written in C. I only wrote up the dummy server in python to be able to
provide a testcase.

The C server works with reasonable speed when connected to a client
written in perl by the way. My employer is quite disappointed with
Python's performance... (He provided the profiler data for the Mac by
the way) I almost wish that I did something wrong, but this does not
seem to be the case.

Nevertheless, I will try out your suggestion.

Thanks for replying,

Thorben

2008/9/11 Antoine Pitrou <report@bugs.python.org>:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Thorben, is the problem still there if you use fork() rather than
> launching a separate thread for the server?
>
> The implementation of the recv() method is straightforward and I don't
> see anything that could cause a huge latency there, it's just a simple
> wrapper over the C library's recv() function. The waiting certainly
> occurs inside the OS rather than inside the Python interpreter.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3766>
> _______________________________________
>
History
Date User Action Args
2008-09-11 16:13:42Thorbensetrecipients: + Thorben, pitrou, giampaolo.rodola, thorben
2008-09-11 16:13:09Thorbenlinkissue3766 messages
2008-09-11 16:13:09Thorbencreate