10d: Calendar performance

[martintaal]

Hi,
I am trying the 10d calendar version, it indeed gives a much better performance.
I did some further profiling, see here for a screenshot of chrome profiler:
http://pasteboard.co/1vVy439P.png

To give a feel for what I test, this is the calendar:
http://pasteboard.co/1vVHPVVS.png

I did the test by moving back and forth to the next and previous date, each with 20 lanes and many events.

In chrome profiler it seems that most/much time is spend in getting getscrollheight/getscrolltop, is this something I can control somehow with things like overflow or with other properties?

gr. Martin

[Isomorphic]

Glad you see some performance improvement. We're going through this with a fine toothed comb and a bunch of other optimizations will hit builds in the coming days.

1) From your screenshot

a) it looks like your events will not overlap - in that case, you can save the time spent calculating how to arrange events by just switching off eventAutoArrange, if you haven't already. That's not a well-used mode, so you may see issues with updating after drag-and-drop or suchlike in that mode - we'll test that out here at HQ in the coming days.

b) how are you rendering those events? When using EventWindow, which APIs did you use to apply your different bodyConstructor in some cases and not others? Since they have images and whatnot, we assume you are still using EventWindow, and not the new (much faster) EventCanvas? Or are you doing that, and then adding your own HTML to it? For best performance, you should use EventCanvas, definitely, and any of the different UI you need should be done, where possible, in HTML or CSS - you don't want to be having each canvas create child widgets if you can help it.

2) how do you provide your events? Is the calendar databound? That is, is it causing fetches whenever you use the next/previous buttons (look in the dev console)? If so, by default that fetch will be retrieving *all* data, and the calendar view will then be iterating over it. We've improved this internally and that will also hit builds some time this week.

3) Note that, because you don't want to pool your event canvases, those canvases are all destroyed when a full refreshEvents() happens (on dataChanged, so next/prev button), and then a new set is created for the events in the new range. Obviously, creation time increases if each canvas creates a bunch of child widgets.

We've already made some changes to reduce the number of calls to getScrollTop/Height() and we'll continue to look into that this week.

[martintaal]

Hey!
1a: I have eventAutoArrange already on false

1b: I am extending the eventcanvas but setting showHeader and showTitle to false. The reason is that I need to show several things in the event: title, coloured side bar, set of icons (differ on information in the event) and a description, some icons have hoovers, some have an onclick action. I am doing this with Layout's so the event consists of one VLayout, with a layout in the top for the header, then a HLayout for the small coloured bar (which is also a layout) and then 2 separate layouts to hold the icons and the description.

2: I don't use datasources right now, I find it easier to read the data explicitly and then I call setdata on the calendar. This because I need to filter the events before showing them in the calendar. I should/can use the datasource also to do this... but this works currently fine for me.

3: when I use eventcanvas pooling then the vertical/horizontal scrolling is a bit less nice, as the eventcanvas pooling means that it will 'hide/cache' the eventcanvas outside of the viewport, so when scrolling back these are redrawn. I would like eventcanvas pooling when moving from one date to the other, but not within one dayview/weekview. So that's the reason that I don't use the eventcanvas pooling (although I would like to).

Regarding the way I do the event content currently. I am considering/checking how I can do it a bit more lightweight, for example each image is now contained in a div. That's not necessary I think, so maybe I should generate the image html directly, or maybe render the content of the event completely myself in html, not sure if tables are faster than divs for rendering in a browser.

Btw, I did the profiling using chrome, I think chrome profiling uses sampling and not tracks exact function calls, so the profile is always an estimate, if you know better javascript profiling approaches then let me know, will try that.

Thanks for your quick responses!

gr. Martin

[Isomorphic]

Note that tomorrow's build of 10.0 has some further optimizations, and these will be the last that hit new builds for now.

In your testing, you should now stop setting useEventCanvasPool to false - in latest code, the old behavior, of recycling around the viewport, is now a "viewport" poolingMode, and there's a new default poolingMode, "data", where canvases will be created while you scroll around and then pooled and reused on dataChanged (next/previous).

Another thing - there's a new feature, canvas.showContextButton, default true - if you return some menuItems from calendar.getEventCanvasMenuItems(), a context button is displayed on rollover, that shows a popup menu with those items - it would be a change of UI, but you could reduce the overhead of creating child image buttons by returning some corresponding menuItems from this new (currently internal) method instead.

[martintaal]

Hi,
Thanks!

I checked and tested and indeed see a large performance improvement. I also now generate direct html for the content of the eventcanvas, that makes a lot of difference also.

In the upcoming weeks I will try to see if there are more/other performance improvements which make sense. Will keep you posted if I notice anything special.

gr. Martin