As a nice to have feature we could aggregate all the data in a single series for all nightly/aurora/etc.
I spent one day on this matter and ..it can be done ...but let me explain why not:
At this point when we make a request for a specific versions/series/etc we get three jsons:
* filter-tree.json
* histograms.json
* [measure]-[by-build-date/-by-submission-date].json
In histograms.json we get all the measures while in filter-tree.json a tree of filters.
After traversing the filter tree and selecting the filter ids we take the list of ids and look in [measure]-[by-build-date/-by-submission-date].json at each entry. Whenever finding a corresponding id we append the data that afterwords is plotted.
Imagine doing that for all versions add a large quantity of data. Remember that the processing is done on the client side (maybe on a slow device?)... it might end up in flames :(...
End of version* story for now...(it could always be done on server side)
Several series. Synchronize with top filter
If you want to preserve all your selections for another version you can do that by synchronizing with the first filter and the selection will get propagated on all other filters.
Because I added "sync with hash" now you can land on the dashboard in two ways:
* by specific state (example:/index.html#nightly/32/CYCLE_COLLECTOR&nightly/25/CYCLE_COLLECTOR)
In this case the filters are not synchronized. If you want to synchronize them you just click the lock button.
* by a default landing
On the default page the sync with first is enabled. If you want to disable the sync you just push the lock button once.
Sync with state
In this version you can preserve your options for another time by saving the url from the dashboard and plotting it in a browser afterwords. This weeks version will come with a refactored and detailed one using some jquery magic. It will get some tinyUrl option too so it can be easily dropped on irc.
By adding multiple versions at some point my dashboard started dying..I began profiling and I got lucky.
In the previous version we used a library called Bootstrap, we had a default implementation for a simple selector that was extended with some shiny bootstrap magic. All was awesome till we started adding several selectors ...
Multiple things might be the cause:
* big overhead for computing and aggregating the data
* d3/nvd3 lib
* selectors
* bad synchronization
* me writing horrible and unoptimized code
* big overhead for computing and aggregating the data
* d3/nvd3 lib
* selectors
* bad synchronization
* me writing horrible and unoptimized code
The last three were a quick fix :D
After switching to a different library, modifying the selector and resolving some bugs I ended up with this comparison:
If you take the same mix of series on load and look at the time spent in the selector you get interesting findings:
Select2 FTW!
Temporary fixes and D3
On the production dashboard the plot comes with a very nice legend that turns unusable when you add several versions. On this weeks version I had to fix that. I removed the legend and put it aside in a scrollable svg. It turns out that even so it is cluttered. I removed the information that doesn't make sense for multiple versions: Summary & Histogram. The functionality is still there but is set visible only for one filter or land on the default page.
This week
Today I had an interesting discussion with one of the users and it turns out that the Summary and Histogram would be a nice to have for multiple versions too. A zoom in the histogram would be nice :D.
I think I figured out why D3 crashes when it gets some particular type of data..(production bug)
I went for a quick fix, but that is not a long term solution. Still looking for some other options. My guess, this bug triggers the tooltip undesired behavior too. Getting at the bottom of this might fix more than one problem.
No comments:
Post a Comment