On May 7, 2007, at 7:46 PM, fumanchu wrote:
> > On May 6, 12:44 pm, kerinin <[EMAIL PROTECTED]> wrote: >> Here's a typical CherryPy profile - does anything here look odd? Can >> anyone interpret what's taking the longest here? I have no >> experience >> with Python profiling... >> >> ncalls tottime percall cumtime percall >> filename:lineno(function) >> 1 0.010 0.010 3.660 3.660 database.py:298(so_rwt) > > First of all, look for lines where the first 'percall' time is > > 0.000. I'm going to guess that so_rwt is shorthand for "SQLObject run > with transaction" or something. So that bit is taking 10 milliseconds. > >> 349/25 0.010 0.000 3.530 0.141 :0(join) > > Then you want to start looking for lines where the number of calls is > large. In this case, the call is to the builtin <str>.join, which is a > C call and should be faster than anything you can replace it with in > Python. ;) But perhaps there are ways to avoid such a large number of > calls to it. > >> 3665/914 0.150 0.000 3.050 0.003 parser.py:207 >> (_coalesce) >> 914 0.010 0.000 2.970 0.003 serialization.py: >> 469(inject_meta_tags) >> 7327/911 0.160 0.000 2.960 0.003 parser.py:172(_track) >> 2732/911 0.070 0.000 2.940 0.003 filter.py: >> 23(apply_matches) > > Now we're getting into serious territory. 7327! calls to the _track > function does not fill one with hope. Whenever you have a split number > in the "ncalls" column, the second number is the number of calls to > the function from outside the function. The first number is the total > number of calls, including recursive calls. So there's an awful lot of > recursion going on, here. > >> 10325/1819 0.170 0.000 0.180 0.000 parser.py:154(_pull) > > This is insane. Rule #1 of optimizing Python: Python function calls > are slow--minimize them. 10,000 calls to a single function is FAR too > many for a typical web page. This _pull method should 1) be unwrapped > from a recursive implementation into a stack-based implementation and > 2) not be called so many times. > >> 1 0.030 0.030 0.160 0.160 :0(ParseFile) > > I/O is a common culprit for performance issues. It might be worth > seeing if this can be loaded into RAM for the duration of the process. > >> 6 0.100 0.017 0.100 0.017 :0(encode_to_file) > > Er..your site is writing files? > > There are other things to look at, but it seems to me at first glance > that your templating engine needs some optimization (or needs to be > replaced). Yep, seems Kid is the culprit here... (_pull, _track, _coalesce.. are all Kid funcs). You're probably better served in this scenario by a faster templating engine... 1.0.2.2 should allow you to use Mako which seems one of the fastest python templating engines ATM. Another, well-tested-in-TG-apps, alternative is Cheetah. Alberto BTW: Thanks for the detailed profile stats analysis! Very enlightening... Any pointers to good reads for further learning? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
