On Apr 21, 2009, at 2:06 AM, Haoyu Bai wrote:

>
> Hi,
>
> We are doing some study on code duplication for various open source
> projects and we found PLY as an interesting case. In PLY, there's a
> high rate of code duplication, which is mostly due to performance
> optimization - there's a method parsedebug(), and an optimized version
> parseopt() by remove the debug statements , and a more optimized
> version parseopt_notrack() by remove more tracking statements . The
> three parsing function with different optimization level produced  a
> lot of code duplication. This optimization technique is quite
> reasonable, since Python is an interpreted language and there's no
> mechanism like macro. But I still  have some question regarding this:
>
> 1. Do you have some comparison data about how performance get improved
> by using this optimization technique?

I don't recall the exact figures off the top of my head, but a CHANGES  
entry
reports as much as a 20% speedup for not tracking positional  
information.

> 2. Is the parseopt() and parseopt_notrack() be manually maintained?
> eg. do we PLY developers have some smart script to strip the "# --!
> DEBUG" sections and generate parseopt() and parseopt_notrack()? If it
> is manually maintained, is it introduced any maintained burden during
> practice?

Right now it's all maintained by hand.    It is annoying to work with  
when I
have to work with it, but this isn't a part of PLY that changes all  
that often.
So, it's not a huge burden in the grand scheme of things.

> 3. Have you considered other techniques (hacking), for example, have
> some code executed in the class definition to generated code for
> parseopt() and parseopt_notrack() as string, and use exec to execute
> them? It will be some extra work during module importing, but would be
> have same performance when calling these method.
>

Not really.   I'm somewhat reluctant to put too much magic into it,  
partly
for portability reasons,  but also for performance reasons.   Having a  
quick
startup time during the module import is also important.
>

Cheers,
Dave


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"ply-hack" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/ply-hack?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to