On Tue, 2 Nov 2021 at 00:20, Shaozhong SHI wrote:
>
>
> On Tue, 2 Nov 2021 at 00:09, MRAB wrote:
>
>> On 2021-11-01 23:02, Shaozhong SHI wrote:
>> > How to configure to improve Python performance in a system like the
>> > following:
>> >
>>
On Tue, Nov 2, 2021 at 11:21 AM Shaozhong SHI wrote:
>
> On Tue, 2 Nov 2021 at 00:09, MRAB wrote:
>
> > On 2021-11-01 23:02, Shaozhong SHI wrote:
> > > How to configure to improve Python performance in a system like the
> > > following:
> >
On Tue, 2 Nov 2021 at 00:09, MRAB wrote:
> On 2021-11-01 23:02, Shaozhong SHI wrote:
> > How to configure to improve Python performance in a system like the
> > following:
> >
> > Windows 10
> >
> > System
> >
> > Processor Intel(R) Core(TM)
On 2021-11-01 23:02, Shaozhong SHI wrote:
How to configure to improve Python performance in a system like the
following:
Windows 10
System
Processor Intel(R) Core(TM) i7-9700 CPU @3.60GHz, 3.60 GHz
Installed memory (RAM) 32.0 GB (31.8 GB usable)
System type: 64-bit Operating System, x64-based
How to configure to improve Python performance in a system like the
following:
Windows 10
System
Processor Intel(R) Core(TM) i7-9700 CPU @3.60GHz, 3.60 GHz
Installed memory (RAM) 32.0 GB (31.8 GB usable)
System type: 64-bit Operating System, x64-based processor
I found that the Python script
On 3/8/14 7:53 AM, JCosta wrote:
I did some work in c# and java and I converted some application to Python; I
noticed Python is much slower than the other languages.
Is this normal ?
Thanks
Your question, and the replies so far in this thread, have overlooked
the difference between language
On 08/03/2014 18:30, JCosta wrote:
Sábado, 8 de Março de 2014 12:53:57 UTC, JCosta escreveu:
I did some work in c# and java and I converted some application to Python; I
noticed Python is much slower than the other languages.
Is this normal ?
Thanks
...
Thanks for the help (C
Sábado, 8 de Março de 2014 12:53:57 UTC, JCosta escreveu:
> I did some work in c# and java and I converted some application to Python; I
> noticed Python is much slower than the other languages.
>
>
>
> Is this normal ?
>
> Thanks
...
Thanks for the help (Chris, Tim and Marko) an
JCosta :
> I did some work in c# and java and I converted some application to
> Python; I noticed Python is much slower than the other languages.
>
> Is this normal ?
Yes. The main reason is the dot notation, which in C through Java is
implemented by the compiler as a fixed offset to a memory str
On 2014-03-08 04:53, JCosta wrote:
> I did some work in c# and java and I converted some application to
> Python; I noticed Python is much slower than the other languages.
>
> Is this normal ?
It depends.
Did you write C#/Java in Python (i.e., use C# or Java idioms in
Python), or did you write P
On Sat, Mar 8, 2014 at 11:53 PM, JCosta wrote:
> I did some work in c# and java and I converted some application to Python; I
> noticed Python is much slower than the other languages.
>
> Is this normal ?
> Thanks
The first thing to look at is the conversion. If you convert idiomatic
Java code i
I did some work in c# and java and I converted some application to Python; I
noticed Python is much slower than the other languages.
Is this normal ?
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Wayne Werner, 03.08.2013 15:09:
> On Fri, 2 Aug 2013, Schneider wrote:
>> I have to write a small SMTP-Relay script (+ some statistic infos) and
>> I'm wondering, if this
>> can be done in python (in terms of performance, of course not in terms of
>> possibility ;) ).
>>
>> It has to handle around
On Fri, 2 Aug 2013, Schneider wrote:
Hi list,
I have to write a small SMTP-Relay script (+ some statistic infos) and
I'm wondering, if this
can be done in python (in terms of performance, of course not in terms
of possibility ;) ).
It has to handle around 2000 mails per hour for at least 8h
On Fri, Aug 2, 2013 at 1:00 PM, Schneider wrote:
> Hi list,
>
> I have to write a small SMTP-Relay script (+ some statistic infos) and I'm
> wondering, if this
> can be done in python (in terms of performance, of course not in terms of
> possibility ;) ).
>
> It has to handle around 2000 mails per
On 2013-08-02, Grant Edwards wrote:
> On 2013-08-02, Schneider wrote:
>
>> I have to write a small SMTP-Relay script (+ some statistic infos)
>> and I'm wondering, if this can be done in python (in terms of
>> performance, of course not in terms of possibility ;) ).
>>
>> It has to handle around
On 2013-08-02, Schneider wrote:
> I have to write a small SMTP-Relay script (+ some statistic infos)
> and I'm wondering, if this can be done in python (in terms of
> performance, of course not in terms of possibility ;) ).
>
> It has to handle around 2000 mails per hour for at least 8hours a day
On Fri, Aug 2, 2013 at 2:16 PM, Schneider wrote:
> Queuing the mails for a while is not possible, because the tool should sit
> between the client and smtp-server.
> It should act as proxy, not as server.
I've written an SMTP proxy (primary purpose: check SPF records;
secondary purpose: rate-limi
On 08/02/2013 03:09 PM, Ray Cote wrote:
- Original Message -
From: "Schneider"
To: python-list@python.org
Sent: Friday, August 2, 2013 8:00:09 AM
Subject: Python performance
Hi list,
I have to write a small SMTP-Relay script (+ some statistic infos)
and
I'm wondering,
- Original Message -
> From: "Schneider"
> To: python-list@python.org
> Sent: Friday, August 2, 2013 8:00:09 AM
> Subject: Python performance
>
> Hi list,
>
> I have to write a small SMTP-Relay script (+ some statistic infos)
> and
> I'm w
On Fri 02 Aug 2013 02:59:26 PM CEST, Tim Chase wrote:
On 2013-08-02 14:00, Schneider wrote:
I have to write a small SMTP-Relay script (+ some statistic infos)
and I'm wondering, if this
can be done in python (in terms of performance, of course not in
terms of possibility ;) ).
It has to handle
On 2013-08-02 14:00, Schneider wrote:
> I have to write a small SMTP-Relay script (+ some statistic infos)
> and I'm wondering, if this
> can be done in python (in terms of performance, of course not in
> terms of possibility ;) ).
>
> It has to handle around 2000 mails per hour for at least 8hour
Hi list,
I have to write a small SMTP-Relay script (+ some statistic infos) and
I'm wondering, if this
can be done in python (in terms of performance, of course not in terms
of possibility ;) ).
It has to handle around 2000 mails per hour for at least 8hours a day
(which does not mean, that
On Sat, Jun 26, 2010 at 7:11 AM, Nobody wrote:
> On Fri, 25 Jun 2010 20:08:27 -0400, geremy condra wrote:
>
>> I have written Haskell that runs faster than C, and Forth that runs
>> faster than C,
>
> Faster than *what* C, though?
Well, than the C it was replacing, which is admittedly not much
of
On Fri, 25 Jun 2010 20:08:27 -0400, geremy condra wrote:
> I have written Haskell that runs faster than C, and Forth that runs
> faster than C,
Faster than *what* C, though?
With Haskell, there's seldom a significant performance hit for using
-fvia-C, so you would probably have been able to get
On Fri, Jun 25, 2010 at 6:18 PM, Mark Lawrence wrote:
> On 25/06/2010 22:25, Stephen Hansen wrote:
>>
>> On Fri, Jun 25, 2010 at 1:51 PM, Mark
>> Lawrencewrote:
>>
>>> On 25/06/2010 16:34, Stephen Hansen wrote:
>>>
>>> Python's slow, sure. But its in practice fast enough for an extremely
>>>
On Fri, Jun 25, 2010 at 3:18 PM, Mark Lawrence wrote:
> On 25/06/2010 22:25, Stephen Hansen wrote:
>
>> On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrence> >wrote:
>>
>> On 25/06/2010 16:34, Stephen Hansen wrote:
>>>
>>> Python's slow, sure. But its in practice fast enough for an extremely
>>>
On 25/06/2010 22:25, Stephen Hansen wrote:
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrencewrote:
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely
broad
range of activities.
What?
What, what?
--S
Python is *NOT* slow,
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrence wrote:
> On 25/06/2010 16:34, Stephen Hansen wrote:
>
> Python's slow, sure. But its in practice fast enough for an extremely
>> broad
>> range of activities.
>>
>>
> What?
>
What, what?
--S
--
http://mail.python.org/mailman/listinfo/python-list
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely broad
range of activities.
What?
Kindest regards.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Jun 24, 2010 at 7:52 PM, Peng Yu wrote:
> http://psyco.sourceforge.net/
>
> The above package can improve python program on 32 bit library. But I
> need to run on 64 bit library. Is there any other module that can help
> improving the performance of python on 64 bit?
>
This is a total as
On Fri, Jun 25, 2010 at 7:01 AM, Tim Wintle wrote:
> On Thu, 2010-06-24 at 21:52 -0500, Peng Yu wrote:
>> http://psyco.sourceforge.net/
>>
>> The above package can improve python program on 32 bit library. But I
>> need to run on 64 bit library. Is there any other module that can help
>> improving
On Thu, 2010-06-24 at 21:52 -0500, Peng Yu wrote:
> http://psyco.sourceforge.net/
>
> The above package can improve python program on 32 bit library. But I
> need to run on 64 bit library. Is there any other module that can help
> improving the performance of python on 64 bit?
As I understand it
http://psyco.sourceforge.net/
The above package can improve python program on 32 bit library. But I
need to run on 64 bit library. Is there any other module that can help
improving the performance of python on 64 bit?
--
Regards,
Peng
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, 2010-02-21 at 23:05 +0100, Martin v. Loewis wrote:
> > It's far from scientific, but I've seen behaviour that's close to a 100%
> > performance penalty on a dual-core linux system:
> >
> >http://www.rfk.id.au/blog/entry/a-gil-adventure-threading2
> >
> > Short story: a particular te
> It's far from scientific, but I've seen behaviour that's close to a 100%
> performance penalty on a dual-core linux system:
>
>http://www.rfk.id.au/blog/entry/a-gil-adventure-threading2
>
> Short story: a particular test suite of mine used to run in around 25
> seconds, but a bit of ctypes
On Sun, 2010-02-21 at 22:22 +0100, Martin v. Loewis wrote:
> John Nagle wrote:
> >I know there's a performance penalty for running Python on a
> > multicore CPU, but how bad is it? I've read the key paper
> > ("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate
> > if the GIL ju
John Nagle wrote:
>I know there's a performance penalty for running Python on a
> multicore CPU, but how bad is it? I've read the key paper
> ("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate
> if the GIL just limited Python to running on one CPU at a time,
> but it's worse t
On Mon, 2010-02-08 at 01:10 -0800, Paul Rubin wrote:
> Stefan Behnel writes:
> > Well, if multi-core performance is so important here, then there's a pretty
> > simple thing the OP can do: switch to lxml.
> >
> > http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/
>
> Well, lxml
Paul Rubin writes:
> Stefan Behnel writes:
>> Well, if multi-core performance is so important here, then there's a pretty
>> simple thing the OP can do: switch to lxml.
>>
>> http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/
>
> Well, lxml is uses libxml2, a fast XML parser w
Le Tue, 02 Feb 2010 15:02:49 -0800, John Nagle a écrit :
> I know there's a performance penalty for running Python on a multicore
> CPU, but how bad is it? I've read the key paper
> ("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate if
> the GIL just limited Python to running on o
Stefan Behnel writes:
> Well, if multi-core performance is so important here, then there's a pretty
> simple thing the OP can do: switch to lxml.
>
> http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/
Well, lxml is uses libxml2, a fast XML parser written in C, but AFAIK it
only
Paul Rubin, 04.02.2010 02:51:
> John Nagle writes:
>> Analysis of each domain is
>> performed in a separate process, but each process uses multiple
>> threads to read process several web pages simultaneously.
>>
>>Some of the threads go compute-bound for a second or two at a time as
>> they par
On Feb 4, 10:46 am, John Nagle wrote:
>
> There's enough intercommunication between the threads working on
> a single site that it's a pain to do them as subprocesses. And I
> definitely don't want to launch subprocesses for each page; the
> Python load time would be worse than the actual work
John Nagle writes:
>There's enough intercommunication between the threads working on
> a single site that it's a pain to do them as subprocesses. And I
> definitely don't want to launch subprocesses for each page; the
> Python load time would be worse than the actual work. The
> subprocess mo
John Nagle writes:
> Analysis of each domain is
> performed in a separate process, but each process uses multiple
> threads to read process several web pages simultaneously.
>
>Some of the threads go compute-bound for a second or two at a time as
> they parse web pages.
You're probably bett
Steve Holden wrote:
John Nagle wrote:
Paul Rubin wrote:
John Nagle writes:
Analysis of each domain is
performed in a separate process, but each process uses multiple
threads to read process several web pages simultaneously.
Some of the threads go compute-bound for a second or two at a tim
John Nagle wrote:
> Paul Rubin wrote:
>> John Nagle writes:
>>> Analysis of each domain is
>>> performed in a separate process, but each process uses multiple
>>> threads to read process several web pages simultaneously.
>>>
>>>Some of the threads go compute-bound for a second or two at a time
Paul Rubin wrote:
John Nagle writes:
Analysis of each domain is
performed in a separate process, but each process uses multiple
threads to read process several web pages simultaneously.
Some of the threads go compute-bound for a second or two at a time as
they parse web pages.
You're pr
On 2/2/2010 9:02 PM, alex23 wrote:
On Feb 3, 9:02 am, John Nagle wrote:
I know there's a performance penalty for running Python on a
multicore CPU, but how bad is it? I've read the key paper
("www.dabeaz.com/python/GIL.pdf"), of course.
It's a shame that Python 3.x is dead to you, other
On Feb 3, 9:02 am, John Nagle wrote:
> I know there's a performance penalty for running Python on a
> multicore CPU, but how bad is it? I've read the key paper
> ("www.dabeaz.com/python/GIL.pdf"), of course.
It's a shame that Python 3.x is dead to you, otherwise you'd be able
to enjoy the ne
On 11:02 pm, na...@animats.com wrote:
I know there's a performance penalty for running Python on a
multicore CPU, but how bad is it? I've read the key paper
("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate
if the GIL just limited Python to running on one CPU at a time,
but
I know there's a performance penalty for running Python on a
multicore CPU, but how bad is it? I've read the key paper
("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate
if the GIL just limited Python to running on one CPU at a time,
but it's worse than that; there's excessive
Antoine Pitrou writes on Thu, 15 Oct 2009 16:25:43 +
(UTC):
> Le Wed, 14 Oct 2009 22:39:14 -0700, John Nagle a écrit :
> >
> > Note that multithreaded compute-bound Python programs really suck
> > on multiprocessors. Adding a second CPU makes the program go slower,
> > due to a lame mec
On Thu, Oct 15, 2009 at 4:35 PM, Aahz wrote:
> In article <
> 1a4707f5-85be-4f5f-ac3e-cf8f5bd21...@b15g2000yqd.googlegroups.com>,
> inaf wrote:
> >
> >I have been following this group for quite some time and I figured
> >(after searching enough on google --and on this group-- and not finding
>
In article <1a4707f5-85be-4f5f-ac3e-cf8f5bd21...@b15g2000yqd.googlegroups.com>,
inaf wrote:
>
>I have been following this group for quite some time and I figured
>(after searching enough on google --and on this group-- and not finding
>anything useful) I could pose this question here. Can anyone
Le Wed, 14 Oct 2009 22:39:14 -0700, John Nagle a écrit :
>
> Note that multithreaded compute-bound Python programs really suck
> on multiprocessors. Adding a second CPU makes the program go slower,
> due to a lame mechanism for resolving conflicts over the global
> interpreter lock.
I'm not
inaf wrote:
I have been following this group for quite some time and I figured
(after searching enough on google --and on this group-- and not
finding anything useful) I could pose this question here. Can anyone
shed some light on python's performance on Solaris?
Note that multithreaded com
On Oct 14, 7:15 am, Antoine Pitrou wrote:
> inaf gmail.com> writes:
>
>
>
> > Good point. I failed to compare the CPU power on these machines.. 32
> > bit linux box I have is 2666 Mhz vs the Solaris zone is 1415 Mhz.. I
> > guess that explains :) Thank you for the tip..
>
> You have to compare no
I use python in almost the same environment. I use it on Joyent and on the
Rackspace cloud. Joyent is faster for a few reasons (cpu bursting and faster
disks) but these aren't real benchmarks until they are on the same machines.
James
On Wed, Oct 14, 2009 at 9:59 AM, Jorgen Grahn
> wrote:
> On
On Wed, 2009-10-14, Antoine Pitrou wrote:
> inaf gmail.com> writes:
>>
>> Good point. I failed to compare the CPU power on these machines.. 32
>> bit linux box I have is 2666 Mhz vs the Solaris zone is 1415 Mhz.. I
>> guess that explains :) Thank you for the tip..
>
> You have to compare not only
inaf gmail.com> writes:
>
> Good point. I failed to compare the CPU power on these machines.. 32
> bit linux box I have is 2666 Mhz vs the Solaris zone is 1415 Mhz.. I
> guess that explains :) Thank you for the tip..
You have to compare not only CPU frequencies but the CPU models.
Recently Sun h
On Oct 11, 6:59 am, Antoine Pitrou wrote:
> inaf gmail.com> writes:
>
>
>
> > My code seem to
> > return lookups from a in memory data structure I build combining bunch
> > of dictionaries and lists 6-8 times faster on a 32 bit Linux box than
> > on a Solaris zone.
>
> Well, if your workload is C
inaf gmail.com> writes:
>
> My code seem to
> return lookups from a in memory data structure I build combining bunch
> of dictionaries and lists 6-8 times faster on a 32 bit Linux box than
> on a Solaris zone.
Well, if your workload is CPU-bound, the issue here is not really Solaris vs.
Linux bu
I have been following this group for quite some time and I figured
(after searching enough on google --and on this group-- and not
finding anything useful) I could pose this question here. Can anyone
shed some light on python's performance on Solaris? My code seem to
return lookups from a in memory
Joe Goldthwaite wrote:
> I didn't know about the getattr function. I tried to search for that
> type of function but not knowing how to word the search request,
> I couldn't find it.
You should really read through chapter 2 (Built-in Objects) of the
library reference. All that stuff is core Pytho
Joe Goldthwaite a écrit :
(snip)
> I guess I still think of decorators as the people
> who got the gym ready for the prom. I've tried getting up to speed on
> decorators but I haven't had much success.
The @decorator syntax is just syntactic sugar for a common use of higher
order functions. So
[EMAIL PROTECTED] wrote:
>Makes perfect sense to me! Think about it:
>
>method 1: looks up the method directly from the object (fastest)
>method 2: looks up __class__, then looks up __dict__, then gets the
>element from __dict__
>method 3: looks up caller, looks up __class__, looks up __dict__, ge
Joe Goldthwaite a écrit :
> Hi everyone,
>
> I'm a developer who's been using python for a couple of years. I wrote a
> fairly large application using it but I was learning the language at the
> same time so it most of the code kind of sucks.
>
> I've learned a lot since then and I've been going
On Sep 26, 7:26 pm, "Joe Goldthwaite" <[EMAIL PROTECTED]> wrote:
> The code gets kind of wordy so I started trying to figure out how to call
> them dynamically since the param type is the same as the method the
> retrieves it. I came up with this;
>
> def getValue(trend, param, per):
>return t
On Sep 26, 2007, at 1:26 PM, Joe Goldthwaite wrote:
> Hi everyone,
>
> I'm a developer who's been using python for a couple of years. I
> wrote a
> fairly large application using it but I was learning the language
> at the
> same time so it most of the code kind of sucks.
>
> I've learned a l
On Sep 26, 2:26 pm, "Joe Goldthwaite" <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> I'm a developer who's been using python for a couple of years. I wrote a
> fairly large application using it but I was learning the language at the
> same time so it most of the code kind of sucks.
>
> I've learned
Hi everyone,
I'm a developer who's been using python for a couple of years. I wrote a
fairly large application using it but I was learning the language at the
same time so it most of the code kind of sucks.
I've learned a lot since then and I've been going through my code trying to
organize it b
I dumped my old fastpython.html web page:
http://manatee.mojam.com/~skip/python/fastpython.html
in favor of a page on the Python wiki:
http://www.python.org/moin/PythonSpeed/PerformanceTips
Now everybody can help fix warts, add content, etc, etc, etc.
References to the old page are red
Stein Morten Sandbech wrote:
The FreeBSD patch, setting the value to 0x10
seems to be enough for most of our zope servers,
however, I've noticed that we get an occasional
server death even with this value. This is on normal
load, but handling many and large CMS operations
in zope/plone.
Just cu
>The FreeBSD patch, setting the value to 0x10
>seems to be enough for most of our zope servers,...
Is that value in /bytes/? In modern solaris implementations
of posix threads, the default stack size is 2 megabytes fo 64
bit machines.
I can't fathom what your performance consideration would
Hi,
I've been googling for any info on the (possible)
effects on python and python applications with
varying values on the THREAD_STACK_SIZE
with respect to performance etc.
The default 0x2 is way to low when running
a Zope 2.7.4 and Plone 2.0.5 site.
The FreeBSD patch, setting the value to 0x1
77 matches
Mail list logo
