Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #16167 > unrolled thread

Re: Does py2app improves speed?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Does py2app improves speed? Dave Angel <d@davea.name> - 2011-11-24 09:27 -0500
    Re: Does py2app improves speed? Alan Meyer <ameyer2@yahoo.com> - 2011-11-28 15:03 -0500
      Re: Does py2app improves speed? Dave Angel <d@davea.name> - 2011-11-28 22:53 -0500

#16167 — Re: Does py2app improves speed?

On 11/24/2011 09:02 AM, Ricardo Mansilla wrote:
> Most of méthods for improving the speed are related to efficient memory management and using specific structures for a specific tasks... But i have already optimized my code (which is very short actually) following all these rules and it is very slow yet.
> Do you think there is another way to do This? Probably i'm missing something here...
>
> On 24/11/2011, at 07:38, Dave Angel<d@davea.name>  wrote:
>
>> On 11/24/2011 08:26 AM, Ricardo Mansilla wrote:
>>> Well, that's sad... I think Im gonna end getting back to C++ for This.  But anyway, thanks a lot for the quick answer...
>>> Bye.
>> Just because Py2app doesn't improve speed doesn't mean there aren't other ways to gain speed, while still using the Python language for all or most of the app. There have been lots of threads on the topic.
>>
>> --
>>
>> DaveA
>>
>
(Please don't top-post.  If you put your comments ahead of the part 
you're quoting, you confuse us)

Several ways to speed up code.

1) use language features to best advantage
2) use 3rd party libraries that do certain things well
3) use best algorithms, subject to #1 and #2
4) have someone else review the code (perhaps on the list, perhaps 
within your own organization)
5) measure  (eg. profile it)
6) use optimizing tools, such as pypy or Cython.
7) rewrite parts of it in another language
8) get a faster processor
9) rewrite it all in another language

It takes experience to choose between these, and each project is 
different.  But even the most experienced developers will frequently 
guess entirely wrong where the bottleneck is, which is why you measure 
if you care.


-- 

DaveA

[toc] | [next] | [standalone]

#16347

On 11/24/2011 9:27 AM, Dave Angel wrote:
...
> Several ways to speed up code.
>
> 1) use language features to best advantage
> 2) use 3rd party libraries that do certain things well
> 3) use best algorithms, subject to #1 and #2
> 4) have someone else review the code (perhaps on the list, perhaps
> within your own organization)
> 5) measure (eg. profile it)
> 6) use optimizing tools, such as pypy or Cython.
> 7) rewrite parts of it in another language
> 8) get a faster processor
> 9) rewrite it all in another language
>
> It takes experience to choose between these, and each project is
> different. But even the most experienced developers will frequently
> guess entirely wrong where the bottleneck is, which is why you measure
> if you care.

I agree that measuring (profiling) is the most critical.

As you say, even the most experienced programmers can guess wrong.  The 
first time I used a profiler a couple of decades ago I was egotistical 
enough to wonder how this thing could help me.  After all, I wrote the 
code.  I knew what it did.  The profiler wasn't going to tell me 
anything I didn't know.

I learned  a little humility after reading the profiler output.  The 
program was spending most of its time in a place that I never dreamed 
was a problem, and a 10 minute fix cut run times in half.

In that particular case there wasn't even a design problem, it was just 
a procedure call inside a tight loop that executed far more often than I 
imagined and could be replaced with a few lines of inline code.

I think the rest of your list is excellent too.

     Alan

[toc] | [prev] | [next] | [standalone]

#16373

On 11/28/2011 03:03 PM, Alan Meyer wrote:
> On 11/24/2011 9:27 AM, Dave Angel wrote:
> ...
>> Several ways to speed up code.
>>
>> 1) use language features to best advantage
>> 2) use 3rd party libraries that do certain things well
>> 3) use best algorithms, subject to #1 and #2
>> 4) have someone else review the code (perhaps on the list, perhaps
>> within your own organization)
>> 5) measure (eg. profile it)
>> 6) use optimizing tools, such as pypy or Cython.
>> 7) rewrite parts of it in another language
>> 8) get a faster processor
>> 9) rewrite it all in another language
>>
>> It takes experience to choose between these, and each project is
>> different. But even the most experienced developers will frequently
>> guess entirely wrong where the bottleneck is, which is why you measure
>> if you care.
>
> I agree that measuring (profiling) is the most critical.
>
> As you say, even the most experienced programmers can guess wrong.  
> The first time I used a profiler a couple of decades ago I was 
> egotistical enough to wonder how this thing could help me.  After all, 
> I wrote the code.  I knew what it did.  The profiler wasn't going to 
> tell me anything I didn't know.
>
> I learned  a little humility after reading the profiler output.  The 
> program was spending most of its time in a place that I never dreamed 
> was a problem, and a 10 minute fix cut run times in half.
>
> In that particular case there wasn't even a design problem, it was 
> just a procedure call inside a tight loop that executed far more often 
> than I imagined and could be replaced with a few lines of inline code.
>
> I think the rest of your list is excellent too.
>
>     Alan

Thanks.  I once had an assignment to speed up a function implementation 
which was obviously slow (I had noted the same thing to the architect 
when I first saw the code;  it would definitely be slow on large data 
sets).  I knew faster algorithms.  But I stopped instead to measure how 
many times it was being called in the particularly slow scenario that 
the customer complained about.  Turns out it wasn't being called at 
all.  I asked the appropriate developer why he had chosen to do it 
another way (expecting he'd say because he knew this function was slow), 
and he gave me an entirely different reason.  I asked him whether he'd 
be willing to call this function if I fixed his complaint about its 
interface, and he agreed.

Now, I rewrote the function, making a change to tighten its interface 
restrictions.  And it cut the customer's wait time from 90 minutes to 
2.  Everyone was happy.

Total time spent, a week.  But I didn't start coding till the 4th day.


-- 

DaveA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web