asked
[meta] Performance of ASK (esp. karma history)
I just got a quick question here about your perceived performance of ASK in regard to load times. I am running IE 8 on a WIN 7 64 bit machine and notice some parts of ASK performing quite slowly. The major area that is slow for me is the karma history. This is slow, especially so for people with high karma - I'm looking at you Matt! ;o). It seems that at around 3000 rep. the graph for karma builds *really* slow and gets worse as you get higher (as of 2010-09-16 it takes 15 seconds to load Matt's history @ rep. of 16471). I imagine this problem is twofold - first to get the data, second to render it. Does anyone else see this happening? If so, maybe we can do some database performance tuning for OSQA (is it SQL Server?), obviously if it is the renderer someone other than myself would need to take a look.
I think the database engine has been mentioned before and, although to my knowledge it hasnt been confirmed, its an open source site so we suspect its an open source solution in the db department too
The problem is known, and is related with the script that renders the graph, which btw, is [flot][1]. Even in IE8 you can get better times if you toggle compatibility view. Please see here . [1]:
http://code.google.com/p/flot/
Since the source code on this site gets updated sometimes, it takes to occasionally hit **Ctrl+F5** to clear stale cache. From what I see, performance of karma hitory is affected only by the graph. One of the problems which can be seen with the naked eye is the scaling of the dots. Usually, the graphs (probably not this one though) are internally implemented to change the scale once the period of time increases. For example, to plot one month worth of data, the graph chooses every point of its respective source. To plot 1 year worth of data, the graph auto-averages (or simply disregards) daily points and uses weekly data and smoothes the line. Since the graph belongs to Google, it is not fair to compare IE and Chrome performance, because the code is specifically written to slow down IE by faking unsupported canvas with javascript emulation. To me it does not matter, I will never have Chrome anywhere near my computers (I like my privacy and Chrome is a bit too invasive for me to tolerate). The first time I started using Microsoft't .NET chart, which is free, clean, includes a bunch of financials, has just as small footprint as Dundas (has rounded corners too), I need nothing else :)
Is your machine slow? IE took about 5 secs on my machine at work... However, Chrome was instant and Firefox was near-instant (maybe 0.25 -> 0.5 secs). I think the issue here maybe two fold: 1. The graph seems to have a lot of data points - really, for that style of graph, I think a weekly summary would give a reasonable indication. I mean, who's going to be doing any integration analysis on it? 2. The javascript engine in IE sucks. Badly. Apparently IE9's JS engine is supposed to suck less. How much less remains to be seen, I guess.
I must admit my experience with most browsing is much better on Chrome than IE. My fellow devs swear by FF, but I prefer Chrome.
It does seem to take a few seconds to load stuff, but the performance isn't too bad.
