launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #06225
Performance Characteristics of Codebrowse
-
To:
launchpad-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Max Kanat-Alexander <mkanat@xxxxxxxxxxxx>
-
Date:
Thu, 20 Jan 2011 21:56:37 -0800
-
Organization:
Bugzilla Project
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
Hey folks. I've been doing some performance analysis of codebrowse and
thought you'd like to know a bit about it. For about the last 24 hours,
here's a broad overview of what codebrowse has spent time doing, in seconds:
ChangeLogUI: 5292.323
ViewUI: 4935.320
InventoryUI: 2332.828
AnnotateUI: 1595.733
RevisionUI: 1038.073
AtomUI: 493.505
FileDiffUI: 269.154
RevLogUI: 86.601
And here's a bit more of a specific breakdown:
Getting information for ChangeLogUI: 5045.049
Rendering ViewUI: 3162.164
Getting information for InventoryUI: 1892.224
Getting information for ViewUI: 1773.157
Rendering AnnotateUI: 1097.353
built revision graph cache: 813.011
Getting information for RevisionUI: 803.542
Getting information for AnnotateUI: 498.380
Rendering InventoryUI: 440.604
Getting information for AtomUI: 430.332
Rendering ChangeLogUI: 247.275
Rendering RevisionUI: 234.531
Getting information for FileDiffUI: 213.583
Getting information for RevLogUI: 84.311
Rendering AtomUI: 63.173
Rendering FileDiffUI: 55.571
Rendering RevLogUI: 2.290
"Rendering ViewUI" is very high on the list because it's counting the
actual time to send file data across the network. (That particular UI
returns a generator does output as it goes.) That's not actually
reflecting a slowness in SimpleTAL.
One interesting thing we can see is that generating caches is in fact
*extremely* valuable--we spend far less time generating the cache than
we spend using it.
Also, this leads me to believe that landing the history_db work on
Launchpad would in fact be incredibly valuable to codebrowse's performance.
I'm also going to be doing some profiling of ChangeLogUI to see if it
can be faster, but I'm not certain that will be possible. It might just
be up to history_db deployment at this point to get significant
performance improvements out of loggerhead.
-Max
--
http://www.bugzillasource.com/
Competent, Friendly Bugzilla, Perl, and IT Services
Follow ups