[Cosmo-dev] Cosmo UI perf profiling

[Matthew Eernisse]

Responses inline ...

Mikeal Rogers wrote:
> Now that windmill is ready and we have tests running we should probably 
> get to work on a performance suite and start generating numbers at each 
> checkpoint.

Have we thought about ways to isolate time on the wire from time spent 
processing JS code in the UI? One way might be to add a 'pre' hook to 
the service calls specifically, and a 'post' hook to the callback.

One of the reasons I did that ad-hoc profiling is because it's so easy 
to see which is which in Firebug, and I was really curious about how 
much time in the week-to-week refresh was being taken up by what.

>> 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%.
>>
> I would be really interested to see the difference in how long this 
> operation takes in other browsers, particularly IE.

Agreed. Unfortunately I don't know of any profiling tools that give you 
that kind of granularity for other browsers. However, we might be able 
to add logging/recording calls in strategic places that would give us an 
idea of how much time is being taken up with the deserializing as a whole.

It's also worth noting too that we're not just doing an eval of the JSON 
-- things would actually likely be even faster if we had gone that route.

> What happened to the gzip work that I saw being done. Nothing would cut 
> our payload down more than using gzip, but does anyone know offhand how 
> much time decompression of gzip takes in the browser?

The gzip work was for the big, built 'dojo.js' file that contains all 
our app code as well the Dojo code our app uses. It's pre-gzipped as 
part of the build, since it's a static resource. We're not doing any 
on-the-fly gzipping of dynamic content.

Gzipping would likely be useful for larger cals like the one I used in 
my testing that had 120-odd events in a single week. The response body 
of the JSON request to pull down those events is about 75K. (We could 
probably chop that in half at least by using Arrays instead of Objects.) 
We also probably need to consider the server-side cost of gzipping 
dynamic content.

Thanks for the feedback -- good stuff.


Matthew