[Cosmo-dev] Cosmo UI perf profiling

[Matthew Eernisse]

After some chatter in IRC this morning, and a message to the list from 
BCM about using the Web UI, I decided to do some Cosmo perf profiling 
with Firebug. This data is obviously not comprehensive or definitive -- 
but it's good to get some real data rather than just speculating. The 
results were pretty interesting.

Request time

Time per request seems to be the biggest expense with the office 
calendar. Here are some numbers for JSON POSTs for week-to-week nav.

Office calendar on osaf.us:

1573ms
995ms
1883ms
868ms
1425ms
913ms
4474ms
2384ms

Office calendar on localhost:

1018ms
463ms
608ms
753ms
1081ms
470ms
1021ms
451ms

(Note my local copy was just running Derby, so even without the hardware 
diff, it's not apples-to-apples.)

120-event-in-a-week calendar (no timezones), osaf.us

546ms
543ms
576ms
561ms
529ms
1388ms
543ms

120-event-in-a-week calendar (20 events w/ Pacific timezone), osaf.us

929ms
3096ms
770ms
786ms
784ms
822ms
785ms

120-event-in-a-week calendar (no timezones), localhost

2105ms
2066ms
2101ms
2114ms
2065ms
2145ms
2092ms

120-event-in-a-week calendar (20 events w/ Pacific timezone), localhost

5543ms
5181ms
4390ms
5571ms
4432ms

You can seen adding timezones to some of the events makes a significant 
difference in the request time both on osaf.us and localhost.

Rendering time

office calendar, both on osaf.us and localhost: 600-800ms

calendar with a single event, both on osaf.us and localhost: 250-300ms

120-event cal, both osaf.us and localhost: 2000-2200ms -- adding 
timezones to events didn't seem to have any impact in render time

With the office cal, the top 5 or 6 offending function calls (out of 209 
listed) that are consistently taking significant chunks are only in the 
7%-12% range. None of those are actual rendering functions.

With the 120-event-in-a-week cal, naturally enough the rendering 
functions actually start showing up as top time-takers in the profile -- 
like 'insert' (which has all the DOM code that creates the lozenges) at 
16-17% and setLozengeAppearance (which sets the colors, background 
gradient for the lozenge, etc.) at 12-13%.

As a BTW, the hundreds of calls to 'convertObject' that deserialize the 
JSON data are taking a very small amount of the render time -- 2%-3.5%.

Conclusions?

For small and medium-sized calendars like the office cal, it seems that 
the request is actually what's chewing up a lot of the time. Events with 
timezones make things take even longer. (I guess that the timezones are 
server processing time, since the size of the data isn't very different.)

For bigger calendars like the 120-event one, it starts to take longer 
for the actual rendering, I'm guessing that adding overlay will get us 
into this over-100-events territory pretty consistently, so it might 
makes sense to start looking at ways to optmize the rendering code for 
larger sets of events.

It does not seem that converting the JSON data to Arrays (instead of the 
Objects we have now) will speed up the deserialization time -- however 
it should reduce the size of the JSON payload since you're only sending 
values instead of keywords/values. It might be good to do some quick 
tests to see what the difference is in request time for Objects versus 
Arrays, but I imagine converting the JSON to Arrays would speed request 
time up at least some.

It's not clear how much of the request time is server-processing time. 
Any way to get those numbers?


Matthew


Brian Moseley wrote:
> one thing i've noticed so far is that switching weeks in the cosmo ui
> is pretty slow, on the order of 2-4 seconds. it's not clear how much
> of that time is spent fetching data from the server vs revivifying it
> into javascript vs rendering the ui updates, but it's definitely
> noticeable. and there are only 13 events this week.
>