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).
Oh, and some cheap DB stats from my ORM's test suite:
01.29 seconds for SQLite :memory: 3.3.3
04.40 seconds for MS SQL Server
11.61 seconds for MySQL 4.1
25.79 seconds for SQLite file DB 3.3.3
In my experience, the time spent implementing one's own timeouts for
SQLite makes it a poor choice for high-concurrency applications (like
websites).
Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
