9.1d Calendar: further performance improvements?

[martintaal]

Hi,
I am testing the build of a few days ago (15th), it is for sure faster!

Still I need to show even faster performance (with daylanes). There is a noticeable lag/wait when eventwindows are redrawn in the calendar when scrolling them in the viewport.

Is there anything I can do/set differently in the calendar (event overlap properties for example or overflow) or in the event window properties which can help performance?
Or something else to minimize the generated html?

Just to get the fastest possible calendar with maybe some loss of functionality.

Thanks!

gr. Martin

[Isomorphic]

If you aren't interested in your events overlapping nicely, you could switch off eventAutoArrange - that should eke out a little more performance. It might have unwanted side-effects too - let us know if you see any that look dubious.

Other than that, we don't plan to make any further optimizations to Calendars in 9.1. That said, major Calendar works are already underway in 10.0, in this area and others, so we may port certain improvements to 9.1 if they're non-intrusive and provide enough benefit.

[martintaal]

okay will try to disable autoarrange.

Other question, does it make sense to move/try the 10d build, does it already have the same features as the 9.1d calendar (specifically daylanes) and extra benefits related to performance?

gr. Martin

[Isomorphic]

Not right now, no - these enhancements are in development - but give it a week or two and you could take a look then.

[martintaal]

Hi,
Okay, I started to search what causes the delays when moving from one date and back. If it is my code or maybe something else.

I found that in dayview with daylanes (and 15 mins per row) you can get a lot of cells and for each cell the getCellDate function on the dayview is called many times and each time it parses the time and combines it with the date. This parsing of the time seems very time consuming (at least the cpu profile shows it).

i noticed that in _getEventScaffolding the datetime is computed but there it is parsed back to a time string. In getCellDate this datetime is usefull, so I changed the getEventScaffolding to set dateTime in the record and then used this in getCellDate. This change resulted in getCellDate disappearing from the profile.

    _getEventScaffolding : function (minsPerRow, startDate) {
        var rowCount = (60 / minsPerRow) * 24,
            data = [],
            row = {label:"", day1:"", day2:"", day3:"", day4:"", day5:"", day6:"", day7:""},
            today = startDate || new Date(),
            date = new Date(today.getFullYear(), today.getMonth(), today.getDate(),0, 0, 0, 0)
        ;

        for (var i=0; i<rowCount; i++) {
            var time = isc.Time.toTime(date);
            data.add(isc.addProperties({}, row, { time: time, dateTime: date.duplicate()}));
            date = isc.DateUtil.dateAdd(date, "mn", minsPerRow, 1);
        }
        return data;

However one other thing I noticed is that much time is spend in the getScrollTop function. Is this something which sounds familiar, is there anything I can do?

Here is the screenshot of the profile showing the getScrollTop:
http://www.screencast.com/users/MartinTaal/folders/Default/media/9ace2194-cbdb-4626-8bfb-bfb34ef91a5e

Btw, I am running latest chrome on linux. Not sure if the chrome profiler is good as I know it works with sampling.

My event window bodies consist of one main layout and three sublayouts, showing a colour, some icons and a text. Are there settings on these layout (like overflow: hidden) which would give the best rendering performance?
I also saw internal properties like manageChildOverflow and notifyAncestorsOnReflow. I noticed in the profile that some time is spend in notifying overflow events. Will one of these properties give better performance?
(I know they are internal :-), just trying to figure out if certain functionalities which have less purpose for my case can be disabled)

Thanks!

gr. Martin

[Isomorphic]

The first thing you mentioned is already addressed in 10.0, although with slightly different code - also, we didn't see your changes to getCellDate(), but for views that cover more than one day, you'd still have to combine the time values with the date value from the column, of course. We'll port this back to 9.1.

And we'll take a look at the getScrollTop calls.

Unfortunately, isc.Window isn't a very lightweight widget - hence, 10.0 comes with a new lightweight EventCanvas. Our advice at this stage would be to hang fire for a few days until that's available in nightlies.

[martintaal]

Thanks for the reply! My only change to getCellDate was to use this dateTime value I created/set in the record.

Another thing I noticed is that getCellValue seems to take time although most cells are empty (only the first column with the time values has a value). So it can maybe be skipped for all columns except for the first one. See the profile screenshot below.

All my comments are with dayLanes, then the number of cells becomes more a parameter in performance.

http://www.screencast.com/users/MartinTaal/folders/Default/media/0a3da206-69e7-4afa-ae52-d49be8bf467a

I also sorted bottom-up and then getScrollTop but even more getScrollHeight showed up:
http://www.screencast.com/users/MartinTaal/folders/Default/media/2ee73973-cd99-4b64-a853-30b9fda548f8

For these tests I moved back and forth between 2 days in the dayview with 20 daylanes and about 50 events on one day.

gr. Martin