Dive Into Python-Chapter 18. Performance Tuning

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:46

lượt xem

Dive Into Python-Chapter 18. Performance Tuning

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'dive into python-chapter 18. performance tuning', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Nội dung Text: Dive Into Python-Chapter 18. Performance Tuning

  1. Chapter 18. Performance Tuning Performance tuning is a many-splendored thing. Just because Python is an interpreted language doesn't mean you shouldn't worry about code optimization. But don't worry about it too much. 18.1. Diving in There are so many pitfalls involved in optimizing your code, it's hard to know where to start. Let's start here: are you sure you need to do it at all? Is your code really so bad? Is it worth the time to tune it? Over the lifetime of your application, how much time is going to be spent running that code, compared to the time spent waiting for a remote database server, or waiting for user input? Second, are you sure you're done coding? Premature optimization is like spreading frosting on a half-baked cake. You spend hours or days (or more)
  2. optimizing your code for performance, only to discover it doesn't do what you need it to do. That's time down the drain. This is not to say that code optimization is worthless, but you need to look at the whole system and decide whether it's the best use of your time. Every minute you spend optimizing code is a minute you're not spending adding new features, or writing documentation, or playing with your kids, or writing unit tests. Oh yes, unit tests. It should go without saying that you need a complete set of unit tests before you begin performance tuning. The last thing you need is to introduce new bugs while fiddling with your algorithms. With these caveats in place, let's look at some techniques for optimizing Python code. The code in question is an implementation of the Soundex algorithm. Soundex was a method used in the early 20th century for categorizing surnames in the United States census. It grouped similar- sounding names together, so even if a name was misspelled, researchers had a chance of finding it. Soundex is still used today for much the same reason, although of course we use computerized database servers now. Most database servers include a Soundex function.
  3. There are several subtle variations of the Soundex algorithm. This is the one used in this chapter: 1. Keep the first letter of the name as-is. 2. Convert the remaining letters to digits, according to a specific table: * B, F, P, and V become 1. * C, G, J, K, Q, S, X, and Z become 2. * D and T become 3. * L becomes 4. * M and N become 5. * R becomes 6. * All other letters become 9. 3. Remove consecutive duplicates. 4. Remove all 9s altogether. 5. If the result is shorter than four characters (the first letter plus three digits), pad the result with trailing zeros. 6. if the result is longer than four characters, discard everything after the fourth character.
  4. For example, my name, Pilgrim, becomes P942695. That has no consecutive duplicates, so nothing to do there. Then you remove the 9s, leaving P4265. That's too long, so you discard the excess character, leaving P426. Another example: Woo becomes W99, which becomes W9, which becomes W, which gets padded with zeros to become W000. Here's a first attempt at a Soundex function: Example 18.1. soundex/stage1/ If you have not already done so, you can download this and other examples used in this book. import string, re charToSoundex = {"A": "9", "B": "1",
  5. "C": "2", "D": "3", "E": "9", "F": "1", "G": "2", "H": "9", "I": "9", "J": "2", "K": "2", "L": "4", "M": "5", "N": "5", "O": "9", "P": "1", "Q": "2", "R": "6", "S": "2",
  6. "T": "3", "U": "9", "V": "1", "W": "9", "X": "2", "Y": "9", "Z": "2"} def soundex(source): "convert string to Soundex equivalent" # Soundex requirements: # source string must be at least 1 character # and must consist entirely of letters allChars = string.uppercase + string.lowercase if not'^[%s]+$' % allChars, source): return "0000"
  7. # Soundex algorithm: # 1. make first character uppercase source = source[0].upper() + source[1:] # 2. translate all other characters to Soundex digits digits = source[0] for s in source[1:]: s = s.upper() digits += charToSoundex[s] # 3. remove consecutive duplicates digits2 = digits[0] for d in digits[1:]: if digits2[-1] != d: digits2 += d
  8. # 4. remove all "9"s digits3 = re.sub('9', '', digits2) # 5. pad end with "0"s to 4 characters while len(digits3) < 4: digits3 += "0" # 6. return first 4 characters return digits3[:4] if __name__ == '__main__': from timeit import Timer names = ('Woo', 'Pilgrim', 'Flingjingwaller') for name in names: statement = "soundex('%s')" % name t = Timer(statement, "from __main__ import soundex") print name.ljust(15), soundex(name), min(t.repeat())
  9. Further Reading on Soundex * Soundexing and Genealogy gives a chronology of the evolution of the Soundex and its regional variations. 18.2. Using the timeit Module The most important thing you need to know about optimizing Python code is that you shouldn't write your own timing function. Timing short pieces of code is incredibly complex. How much processor time is your computer devoting to running this code? Are there things running in the background? Are you sure? Every modern computer has background processes running, some all the time, some intermittently. Cron jobs fire off at consistent intervals; background services occasionally “wake up” to do useful things like check for new mail, connect to instant messaging servers, check for application updates, scan for viruses, check whether a disk has been inserted into your CD drive in the last 100 nanoseconds, and so on. Before you start your timing tests, turn everything off and disconnect from the network. Then turn off all the things you forgot to turn off the first time,
  10. then turn off the service that's incessantly checking whether the network has come back yet, then ... And then there's the matter of the variations introduced by the timing framework itself. Does the Python interpreter cache method name lookups? Does it cache code block compilations? Regular expressions? Will your code have side effects if run more than once? Don't forget that you're dealing with small fractions of a second, so small mistakes in your timing framework will irreparably skew your results. The Python community has a saying: “Python comes with batteries included.” Don't write your own timing framework. Python 2.3 comes with a perfectly good one called timeit. Example 18.2. Introducing timeit If you have not already done so, you can download this and other examples used in this book. >>> import timeit >>> t = timeit.Timer("soundex.soundex('Pilgrim')",
  11. ... "import soundex") 1 >>> t.timeit() 2 8.21683733547 >>> t.repeat(3, 2000000) 3 [16.48319309109, 16.46128984923, 16.44203948912] 1 The timeit module defines one class, Timer, which takes two arguments. Both arguments are strings. The first argument is the statement you wish to time; in this case, you are timing a call to the Soundex function within the soundex with an argument of 'Pilgrim'. The second argument to the Timer class is the import statement that sets up the environment for the statement. Internally, timeit sets up an isolated virtual environment, manually executes the setup statement (importing the soundex module), then manually compiles and executes the timed statement (calling the Soundex function). 2 Once you have the Timer object, the easiest thing to do is call timeit(), which calls your function 1 million times and returns the number of seconds it took to do it. 3 The other major method of the Timer object is repeat(), which takes two optional arguments. The first argument is the number of times to repeat the entire test, and the second argument is the number of times to call the timed statement within each test. Both arguments are optional, and they
  12. default to 3 and 1000000 respectively. The repeat() method returns a list of the times each test cycle took, in seconds. Tip You can use the timeit module on the command line to test an existing Python program, without modifying the code. See for documentation on the command- line flags. Note that repeat() returns a list of times. The times will almost never be identical, due to slight variations in how much processor time the Python interpreter is getting (and those pesky background processes that you can't get rid of). Your first thought might be to say “Let's take the average and call that The True Number.” In fact, that's almost certainly wrong. The tests that took longer didn't take longer because of variations in your code or in the Python interpreter; they took longer because of those pesky background processes, or other factors outside of the Python interpreter that you can't fully eliminate. If the different timing results differ by more than a few percent, you still have too much variability to trust the results. Otherwise, take the minimum time and discard the rest.
  13. Python has a handy min function that takes a list and returns the smallest value: >>> min(t.repeat(3, 1000000)) 8.22203948912 Tip The timeit module only works if you already know what piece of code you need to optimize. If you have a larger Python program and don't know where your performance problems are, check out the hotshot module. 18.3. Optimizing Regular Expressions The first thing the Soundex function checks is whether the input is a non- empty string of letters. What's the best way to do this? If you answered “regular expressions”, go sit in the corner and contemplate your bad instincts. Regular expressions are almost never the right answer; they should be avoided whenever possible. Not only for performance reasons, but simply because they're difficult to debug and maintain. Also for performance reasons.
  14. This code fragment from soundex/stage1/ checks whether the function argument source is a word made entirely of letters, with at least one letter (not the empty string): allChars = string.uppercase + string.lowercase if not'^[%s]+$' % allChars, source): return "0000" How does perform? For convenience, the __main__ section of the script contains this code that calls the timeit module, sets up a timing test with three different names, tests each name three times, and displays the minimum time for each: if __name__ == '__main__': from timeit import Timer names = ('Woo', 'Pilgrim', 'Flingjingwaller') for name in names: statement = "soundex('%s')" % name
  15. t = Timer(statement, "from __main__ import soundex") print name.ljust(15), soundex(name), min(t.repeat()) So how does perform with this regular expression? C:\samples\soundex\stage1>python Woo W000 19.3356647283 Pilgrim P426 24.0772053431 Flingjingwaller F452 35.0463220884 As you might expect, the algorithm takes significantly longer when called with longer names. There will be a few things we can do to narrow that gap (make the function take less relative time for longer input), but the nature of the algorithm dictates that it will never run in constant time. The other thing to keep in mind is that we are testing a representative sample of names. Woo is a kind of trivial case, in that it gets shorted down to a single letter and then padded with zeros. Pilgrim is a normal case, of average length and a mixture of significant and ignored letters. Flingjingwaller is
  16. extraordinarily long and contains consecutive duplicates. Other tests might also be helpful, but this hits a good range of different cases. So what about that regular expression? Well, it's inefficient. Since the expression is testing for ranges of characters (A-Z in uppercase, and a-z in lowercase), we can use a shorthand regular expression syntax. Here is soundex/stage1/ if not'^[A-Za-z]+$', source): return "0000" timeit says is slightly faster than, but nothing to get terribly excited about: C:\samples\soundex\stage1>python Woo W000 17.1361133887 Pilgrim P426 21.8201693232 Flingjingwaller F452 32.7262294509
  17. We saw in Section 15.3, “Refactoring” that regular expressions can be compiled and reused for faster results. Since this regular expression never changes across function calls, we can compile it once and use the compiled version. Here is soundex/stage1/ isOnlyChars = re.compile('^[A-Za-z]+$').search def soundex(source): if not isOnlyChars(source): return "0000" Using a compiled regular expression in is significantly faster: C:\samples\soundex\stage1>python Woo W000 14.5348347346 Pilgrim P426 19.2784703084 Flingjingwaller F452 30.0893873383
  18. But is this the wrong path? The logic here is simple: the input source needs to be non-empty, and it needs to be composed entirely of letters. Wouldn't it be faster to write a loop checking each character, and do away with regular expressions altogether? Here is soundex/stage1/ if not source: return "0000" for c in source: if not ('A'
  19. Pilgrim P426 22.2753567842 Flingjingwaller F452 37.5845122774 Why isn't faster? The answer lies in the interpreted nature of Python. The regular expression engine is written in C, and compiled to run natively on your computer. On the other hand, this loop is written in Python, and runs through the Python interpreter. Even though the loop is relatively simple, it's not simple enough to make up for the overhead of being interpreted. Regular expressions are never the right answer... except when they are. It turns out that Python offers an obscure string method. You can be excused for not knowing about it, since it's never been mentioned in this book. The method is called isalpha(), and it checks whether a string contains only letters. This is soundex/stage1/ if (not source) and (not source.isalpha()): return "0000"
  20. How much did we gain by using this specific method in Quite a bit. C:\samples\soundex\stage1>python Woo W000 13.5069504644 Pilgrim P426 18.2199394057 Flingjingwaller F452 28.9975225902 Example 18.3. Best Result So Far: soundex/stage1/ import string, re charToSoundex = {"A": "9", "B": "1", "C": "2", "D": "3",



Đồng bộ tài khoản